From: pebenito@ieee.org (Chris PeBenito) Date: Wed, 17 Aug 2016 16:02:05 -0400 Subject: [refpolicy] [PATCH] Update the lvm module In-Reply-To: <1471611016.2903.13.camel@trentalancia.net> 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> <1471611016.2903.13.camel@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/19/16 08:50, Guido Trentalancia wrote: > On Wed, 17/08/2016 at 15.34 -0400, Chris PeBenito wrote: >> On 08/18/16 11:48, Guido Trentalancia wrote: >>> 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. >>>>> @@ -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... I meant new from SELinux's perspective. New in that it has no specific object class (the socket code itself may not be new). >>>> 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'm not familiar with a sequential packet socket, but I suspect it should be a new object class, rather than mapped to unix_stream_socket. This discussion would be best for the main SELinux list, as it is a kernel change, where Paul Moore and others can comment. >>> 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. That's fine, I only suggested it because not everyone is comfortable with digging through source code. -- Chris PeBenito