From: guido@trentalancia.net (Guido Trentalancia)
Date: Fri, 19 Aug 2016 14:50:16 +0200
Subject: [refpolicy] [PATCH] Update the lvm module
In-Reply-To: <4319fa30-c6ef-652b-13df-c46a484b8ef5@ieee.org>
References: <1426268394.997176.1471208149952.JavaMail.open-xchange@popper06.register.it>
	<39ff9127-65f4-6c38-3ac3-a413f1ae2edc@ieee.org>
	<1471535328.14586.11.camel@trentalancia.net>
	<4319fa30-c6ef-652b-13df-c46a484b8ef5@ieee.org>
Message-ID: <1471611016.2903.13.camel@trentalancia.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Christopher.

On Wed, 17/08/2016 at 15.34 -0400, Chris PeBenito wrote:
> On 08/18/16 11:48, Guido Trentalancia wrote:
> > Hello Christopher !
> > 
> > Thanks for getting back on this proposed patch.
> > 
> > On Mon, 15/08/2016 at 16.26 -0400, Chris PeBenito wrote:
> > > On 08/14/16 16:55, Guido Trentalancia wrote:
> > > > Update the lvm module to add a permission needed by cryptsetup.
> > > > 
> > > > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > > > ---
> > > > ?policy/modules/system/lvm.te |????5 +++++
> > > > ?1 file changed, 5 insertions(+)
> > > > 
> > > > --- refpolicy-git-06082016-orig/policy/modules/system/lvm.te	
> > > > 2016-08-06
> > > > 21:26:43.305774396 +0200
> > > > +++ refpolicy-git-06082016/policy/modules/system/lvm.te	
> > > > 2016
> > > > -08-14
> > > > 22:46:26.233136106 +0200
> > > > @@ -179,6 +179,7 @@ allow lvm_t self:fifo_file manage_fifo_f
> > > > ?allow lvm_t self:unix_dgram_socket create_socket_perms;
> > > > ?allow lvm_t self:netlink_kobject_uevent_socket
> > > > create_socket_perms;
> > > > ?allow lvm_t self:sem create_sem_perms;
> > > > +allow lvm_t self:socket create_stream_socket_perms;
> > > 
> > > "socket" object class means that there is no specific socket
> > > class
> > > for
> > > this type of socket.??Can you determine what kind of socket it is

I have looked at the code and the only type of socket being used is the
sequential packet socket.

Please note that this is not an entirely new socket type, although at
the moment for some reason the SELinux kernel code does not distinguish
it from a unix stream socket.

For some reason at bootup, immediately after loading the policy, I
suppose while running from the initramfs, cryptsetup (lvm) requires
create_stream_socket_perms for a generic "socket" instead of a
sequential packet socket (that would show up as as unix stream socket,
for the reason mentioned above).

I am pretty much sure that it's not a new socket type, but for some
reason it looks like that...

> > > so
> > > we
> > > can document it here???Also generating a kernel patch and policy
> > > patch
> > > to create a new object class for it would be good too.

It's all ready if we want to switch from the actual kernel behavior to
treat a sequential packet socket as a unix stream socket from the more
meaningful option of distinguishing between the two types.

I just wanted to double-check things with you because I am pretty sure
it's not a "new socket type" as you meant in your reply.

Please have a quick look at the cryptsetup code first (just do grep -r
"SOCK_" or "socket") and then let me know.

> > I think it should be a sequential packet socket used for the user-
> > space
> > interface to the kernel Crypto API.
> > 
> > I will first prepare a patch for the Reference Policy and then try
> > to
> > create a patch for the kernel.
> > 
> > After the sequential packet socket patch will be applied to the
> > Reference Policy, I can modify this lvm patch and resubmit it.
> 
> My preference would be to still have the generic "socket"
> permissions?
> until the new socket type is generally available, so I think you
> should:

Beware, it won't show as a sequential packet socket even if the kernel
patch is applied (although for other modules, such as udev, the patch
is doing its job properly).

> 1. try to verify the socket type (e.g. strace)

It's much simpler to look at the code directly, see above.

> 2. update this patch with a comment about the socket type
> 3. submit a kernel patch to the selinux list for the new object class
> 4. once the kernel patch is accepted, create a new refpolicy patch
> that?
> adds the new socket class
> 5. create a new refpolicy patch that adds the new permissions to LVM.

Please let me know...

Best regards,

Guido