[refpolicy] [PATCH] Update the lvm module

[refpolicy] [PATCH] Update the lvm module

[Guido Trentalancia]

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;
 
 allow lvm_t self:unix_stream_socket { connectto create_stream_socket_perms };
 allow lvm_t clvmd_t:unix_stream_socket { connectto rw_socket_perms };
@@ -253,6 +254,8 @@ dev_dontaudit_getattr_generic_chr_files(
 dev_dontaudit_getattr_generic_blk_files(lvm_t)
 dev_dontaudit_getattr_generic_pipes(lvm_t)
 dev_create_generic_dirs(lvm_t)
+# the following one is needed by cryptsetup
+dev_getattr_fs(lvm_t)
 
 domain_use_interactive_fds(lvm_t)
 domain_read_all_domains_state(lvm_t)

[refpolicy] [PATCH] Update the lvm module

[Dominick Grift]

On 08/14/2016 10:55 PM, 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;

allow lvm_t self:socket create_socket_perms;

>  
>  allow lvm_t self:unix_stream_socket { connectto create_stream_socket_perms };
>  allow lvm_t clvmd_t:unix_stream_socket { connectto rw_socket_perms };
> @@ -253,6 +254,8 @@ dev_dontaudit_getattr_generic_chr_files(
>  dev_dontaudit_getattr_generic_blk_files(lvm_t)
>  dev_dontaudit_getattr_generic_pipes(lvm_t)
>  dev_create_generic_dirs(lvm_t)
> +# the following one is needed by cryptsetup
> +dev_getattr_fs(lvm_t)
>  
>  domain_use_interactive_fds(lvm_t)
>  domain_read_all_domains_state(lvm_t)
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/3c394a23/attachment.bin 

[refpolicy] [PATCH] Update the lvm module

[Dominick Grift]

On 08/14/2016 10:59 PM, Dominick Grift wrote:
> On 08/14/2016 10:55 PM, 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;
> 
> allow lvm_t self:socket create_socket_perms;

Hmm no, I think you are right here. Sorry

> 
>>  
>>  allow lvm_t self:unix_stream_socket { connectto create_stream_socket_perms };
>>  allow lvm_t clvmd_t:unix_stream_socket { connectto rw_socket_perms };
>> @@ -253,6 +254,8 @@ dev_dontaudit_getattr_generic_chr_files(
>>  dev_dontaudit_getattr_generic_blk_files(lvm_t)
>>  dev_dontaudit_getattr_generic_pipes(lvm_t)
>>  dev_create_generic_dirs(lvm_t)
>> +# the following one is needed by cryptsetup
>> +dev_getattr_fs(lvm_t)
>>  
>>  domain_use_interactive_fds(lvm_t)
>>  domain_read_all_domains_state(lvm_t)
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
> 
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/fa9167f2/attachment.bin 

[refpolicy] [PATCH] Update the lvm module

[Chris PeBenito]

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 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.

-- 
Chris PeBenito

[refpolicy] [PATCH] Update the lvm module

[Chris PeBenito]

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 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.


-- 
Chris PeBenito

[refpolicy] [PATCH] Update the lvm module

[Chris PeBenito]

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

[refpolicy] [PATCH] Update the lvm module

[Guido Trentalancia]

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 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.

Is that all right ?

Best regards,

Guido

[refpolicy] [PATCH] Update the lvm module

[Guido Trentalancia]

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

[refpolicy] [PATCH] Update the lvm module

[Guido Trentalancia]

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.

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
> > > 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

[refpolicy] [PATCH] Update the lvm module

[Chris PeBenito]

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 <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
>>>> 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

[refpolicy] [PATCH v2] Update the lvm module

[Guido Trentalancia]

Update the lvm module to add a permission needed by cryptsetup.

At the moment the SELinux kernel code is not able yet to distinguish
the sockets in the AF_ALG namespace that are used for interfacing to
the kernel Crypto API.

In the future the SELinux kernel code will be updated to distinguish
the new socket class and so this permission will change its class
from the generic "socket" to the new socket (e.g. "alg_socket").

Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
---
 policy/modules/system/lvm.te |    4 ++++
 1 file changed, 4 insertions(+)

--- refpolicy-git-06082016-orig/policy/modules/system/lvm.te	2016-08-06 21:26:43.305774396 +0200
+++ refpolicy-git-06082016-new/policy/modules/system/lvm.te	2016-09-05 19:01:46.798218649 +0200
@@ -179,6 +179,8 @@ 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;
+# gt: the following is for sockets in the AF_ALG namespace (userspace interface to the kernel Crypto API)
+allow lvm_t self:socket create_stream_socket_perms;
 
 allow lvm_t self:unix_stream_socket { connectto create_stream_socket_perms };
 allow lvm_t clvmd_t:unix_stream_socket { connectto rw_socket_perms };
@@ -253,6 +255,8 @@ dev_dontaudit_getattr_generic_chr_files(
 dev_dontaudit_getattr_generic_blk_files(lvm_t)
 dev_dontaudit_getattr_generic_pipes(lvm_t)
 dev_create_generic_dirs(lvm_t)
+# the following one is needed by cryptsetup
+dev_getattr_fs(lvm_t)
 
 domain_use_interactive_fds(lvm_t)
 domain_read_all_domains_state(lvm_t)

[refpolicy] [PATCH v2] Update the lvm module

[Chris PeBenito]

On 09/05/16 13:09, Guido Trentalancia wrote:
> Update the lvm module to add a permission needed by cryptsetup.
>
> At the moment the SELinux kernel code is not able yet to distinguish
> the sockets in the AF_ALG namespace that are used for interfacing to
> the kernel Crypto API.
>
> In the future the SELinux kernel code will be updated to distinguish
> the new socket class and so this permission will change its class
> from the generic "socket" to the new socket (e.g. "alg_socket").
>
> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> ---
>  policy/modules/system/lvm.te |    4 ++++
>  1 file changed, 4 insertions(+)
>
> --- refpolicy-git-06082016-orig/policy/modules/system/lvm.te	2016-08-06 21:26:43.305774396 +0200
> +++ refpolicy-git-06082016-new/policy/modules/system/lvm.te	2016-09-05 19:01:46.798218649 +0200
> @@ -179,6 +179,8 @@ 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;
> +# gt: the following is for sockets in the AF_ALG namespace (userspace interface to the kernel Crypto API)
> +allow lvm_t self:socket create_stream_socket_perms;
>
>  allow lvm_t self:unix_stream_socket { connectto create_stream_socket_perms };
>  allow lvm_t clvmd_t:unix_stream_socket { connectto rw_socket_perms };
> @@ -253,6 +255,8 @@ dev_dontaudit_getattr_generic_chr_files(
>  dev_dontaudit_getattr_generic_blk_files(lvm_t)
>  dev_dontaudit_getattr_generic_pipes(lvm_t)
>  dev_create_generic_dirs(lvm_t)
> +# the following one is needed by cryptsetup
> +dev_getattr_fs(lvm_t)
>
>  domain_use_interactive_fds(lvm_t)
>  domain_read_all_domains_state(lvm_t)

Merged.

-- 
Chris PeBenito