From mboxrd@z Thu Jan 1 00:00:00 1970 From: pebenito@ieee.org (Chris PeBenito) Date: Mon, 5 Sep 2016 10:12:11 -0400 Subject: [refpolicy] [PATCH] Update the lvm module In-Reply-To: <1472903649.15198.7.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> <1472903649.15198.7.camel@trentalancia.net> Message-ID: <6e0eed68-6b95-d9e6-ba8d-979767649e4d@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 09/03/16 07:54, Guido Trentalancia wrote: > Hello Christopher. > > This patch was on hold... > > However, on the SELinux mailing list they decided not to apply the new > socket permission patch for the kernel, because they said it's not > worth changing the code for only one new socket type when there are > several others that need to be implemented. > > I don't know if and when I can implement all the changes in the kernel > for all the new socket types, so I would suggest that for the time > being you apply this patch as it is and then, if and when the new > sockets are implemented in the SELinux kernel code, we can amend things > easily. > > What do you say ? > > As far as I remember, the socket code in cryptsetup can be blocked by > the missing create_stream_socket_perms permission that this patch adds. > I remember at some point the test machine wasn't booting anymore > without such permission. Ok, then it would need a comment in the policy for the socket type, so when the socket is finally implemented, we can fix the policy. > 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 >>>>> --- >>>>> 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 >>>> 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. >>> >>> 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: >> >> 1. try to verify the socket type (e.g. strace) >> 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. > > Regards, > > Guido > -- Chris PeBenito