Hi,
I use kerberized NFS and there are some issues in the policy. The
problem stems from caching the nfs ticket. When I run in permissive
mode, I kinit and klist shows the krbtgt as usual. When I then ls the
nfs dir i get a second ticket: nfs/hostname.perfinion.com at PERFINION.COM
and everything is fine and responsive.
When I run with enforcing mode I do not get that second ticket and i get
the following denial:
{ write } for pid=22323 comm="rpc.gssd" path="/tmp/krb5cc_1000" dev="tmpfs"
ino=3528734 scontext=system_u:system_r:gssd_t
tcontext=staff_u:object_r:user_tmp_t tclass=file
and the second ticket never shows up in klist. This means that every
single access to the nfs share it has to get a new nfs ticket which adds
a long delay to everything.
I am not that familiar with how the kerberos parts of the policy works
so I thought asking here before sending patches is better.
What should the label be on /tmp/krb5cc_<uid>? The krb5ccmachine file
looks correct but user_tmp_t looks wrong. I found krb5_host_rcache_t in
the policy but that doesnt look right either, that should be server side
not client.
-rw-------. 1 jason users staff_u:object_r:user_tmp_t 1118 Jul 12
13:07 krb5cc_1000
-rw-------. 1 root root system_u:object_r:gssd_tmp_t 1207 Jul 12
09:29 krb5ccmachine_PERFINION.COM
Does anyone else use kerberized NFS with selinux and have any additions
to the policy that can be shared?
Thanks,
-- Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 951 bytes
Desc: Digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140712/ecdb77e9/attachment.bin
On 07/12/2014 06:41 AM, Jason Zaman wrote:
> Hi,
>
> I use kerberized NFS and there are some issues in the policy. The
> problem stems from caching the nfs ticket. When I run in permissive
> mode, I kinit and klist shows the krbtgt as usual. When I then ls the
> nfs dir i get a second ticket: nfs/hostname.perfinion.com at PERFINION.COM
> and everything is fine and responsive.
>
> When I run with enforcing mode I do not get that second ticket and i get
> the following denial:
>
> { write } for pid=22323 comm="rpc.gssd" path="/tmp/krb5cc_1000" dev="tmpfs"
> ino=3528734 scontext=system_u:system_r:gssd_t
> tcontext=staff_u:object_r:user_tmp_t tclass=file
>
> and the second ticket never shows up in klist. This means that every
> single access to the nfs share it has to get a new nfs ticket which adds
> a long delay to everything.
>
> I am not that familiar with how the kerberos parts of the policy works
> so I thought asking here before sending patches is better.
>
> What should the label be on /tmp/krb5cc_<uid>? The krb5ccmachine file
> looks correct but user_tmp_t looks wrong. I found krb5_host_rcache_t in
> the policy but that doesnt look right either, that should be server side
> not client.
>
> -rw-------. 1 jason users staff_u:object_r:user_tmp_t 1118 Jul 12
> 13:07 krb5cc_1000
> -rw-------. 1 root root system_u:object_r:gssd_tmp_t 1207 Jul 12
> 09:29 krb5ccmachine_PERFINION.COM
>
> Does anyone else use kerberized NFS with selinux and have any additions
> to the policy that can be shared?
>
> Thanks,
> -- Jason
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On Fedora/RHEL7 we have
sesearch -A -s gssd_t -t user_tmp_t -c file -C
Found 5 semantic av rules:
allow daemon user_tmp_t : file { getattr append } ;
allow domain tmpfile : file { ioctl read getattr lock append } ;
allow gssd_t user_tmp_t : file { ioctl read write getattr lock append
open } ;
ET allow gssd_t user_tmp_type : file { ioctl read getattr lock open } ;
[ gssd_read_tmp ]
ET allow gssd_t user_tmp_t : file { ioctl read write create getattr
setattr lock append unlink link rename open } ; [ gssd_read_tmp ]
Turning on the gssd_read_tmp boolean would allow it to update the
Credential Cache.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140714/d3e397bf/attachment.html
On Mon, Jul 14, 2014 at 07:10:55AM -0400, Daniel J Walsh wrote:
> On 07/12/2014 06:41 AM, Jason Zaman wrote:
>
> Hi,
>
> I use kerberized NFS and there are some issues in the policy. The
> problem stems from caching the nfs ticket. When I run in permissive
> mode, I kinit and klist shows the krbtgt as usual. When I then ls the
> nfs dir i get a second ticket: [1]nfs/hostname.perfinion.com at PERFINION.COM
> and everything is fine and responsive.
>
> When I run with enforcing mode I do not get that second ticket and i get
> the following denial:
>
> { write } for pid=22323 comm="rpc.gssd" path="/tmp/krb5cc_1000" dev="tmpfs"
> ino=3528734 scontext=system_u:system_r:gssd_t
> tcontext=staff_u:object_r:user_tmp_t tclass=file
>
> and the second ticket never shows up in klist. This means that every
> single access to the nfs share it has to get a new nfs ticket which adds
> a long delay to everything.
>
> I am not that familiar with how the kerberos parts of the policy works
> so I thought asking here before sending patches is better.
>
> What should the label be on /tmp/krb5cc_<uid>? The krb5ccmachine file
> looks correct but user_tmp_t looks wrong. I found krb5_host_rcache_t in
> the policy but that doesnt look right either, that should be server side
> not client.
>
> -rw-------. 1 jason users staff_u:object_r:user_tmp_t 1118 Jul 12
> 13:07 krb5cc_1000
> -rw-------. 1 root root system_u:object_r:gssd_tmp_t 1207 Jul 12
> 09:29 krb5ccmachine_PERFINION.COM
>
> Does anyone else use kerberized NFS with selinux and have any additions
> to the policy that can be shared?
>
> Thanks,
> -- Jason
>
> _______________________________________________
> refpolicy mailing list
> [2]refpolicy at oss.tresys.com
> [3]http://oss.tresys.com/mailman/listinfo/refpolicy
>
> On Fedora/RHEL7 we have
>
> sesearch -A -s gssd_t -t user_tmp_t -c file -C
> Found 5 semantic av rules:
> ?? allow daemon user_tmp_t : file { getattr append } ;
> ?? allow domain tmpfile : file { ioctl read getattr lock append } ;
> ?? allow gssd_t user_tmp_t : file { ioctl read write getattr lock append
> open } ;
> ET allow gssd_t user_tmp_type : file { ioctl read getattr lock open } ; [
> gssd_read_tmp ]
> ET allow gssd_t user_tmp_t : file { ioctl read write create getattr
> setattr lock append unlink link rename open } ; [ gssd_read_tmp ]
>
> Turning on the gssd_read_tmp boolean would allow it to update the
> Credential Cache.
Hmm, refpol does not have that. I will make a patch and send it
(although gssd_read_tmp is not that great of a name since it writes).
Should the cred cache really be labelled user_tmp_t tho? Is having
something like user_krb_t not a better idea?
I am also going to test out the storing it in the kernels keyring (I was
pointed towards that by tfirg on #selinux).
-- Jason
On 07/20/2014 08:39 AM, Jason Zaman wrote:
> On Mon, Jul 14, 2014 at 07:10:55AM -0400, Daniel J Walsh wrote:
>> On 07/12/2014 06:41 AM, Jason Zaman wrote:
>>
>> Hi,
>>
>> I use kerberized NFS and there are some issues in the policy. The
>> problem stems from caching the nfs ticket. When I run in permissive
>> mode, I kinit and klist shows the krbtgt as usual. When I then ls the
>> nfs dir i get a second ticket: [1]nfs/hostname.perfinion.com at PERFINION.COM
>> and everything is fine and responsive.
>>
>> When I run with enforcing mode I do not get that second ticket and i get
>> the following denial:
>>
>> { write } for pid=22323 comm="rpc.gssd" path="/tmp/krb5cc_1000" dev="tmpfs"
>> ino=3528734 scontext=system_u:system_r:gssd_t
>> tcontext=staff_u:object_r:user_tmp_t tclass=file
>>
>> and the second ticket never shows up in klist. This means that every
>> single access to the nfs share it has to get a new nfs ticket which adds
>> a long delay to everything.
>>
>> I am not that familiar with how the kerberos parts of the policy works
>> so I thought asking here before sending patches is better.
>>
>> What should the label be on /tmp/krb5cc_<uid>? The krb5ccmachine file
>> looks correct but user_tmp_t looks wrong. I found krb5_host_rcache_t in
>> the policy but that doesnt look right either, that should be server side
>> not client.
>>
>> -rw-------. 1 jason users staff_u:object_r:user_tmp_t 1118 Jul 12
>> 13:07 krb5cc_1000
>> -rw-------. 1 root root system_u:object_r:gssd_tmp_t 1207 Jul 12
>> 09:29 krb5ccmachine_PERFINION.COM
>>
>> Does anyone else use kerberized NFS with selinux and have any additions
>> to the policy that can be shared?
>>
>> Thanks,
>> -- Jason
>>
>> _______________________________________________
>> refpolicy mailing list
>> [2]refpolicy at oss.tresys.com
>> [3]http://oss.tresys.com/mailman/listinfo/refpolicy
>>
>> On Fedora/RHEL7 we have
>>
>> sesearch -A -s gssd_t -t user_tmp_t -c file -C
>> Found 5 semantic av rules:
>> allow daemon user_tmp_t : file { getattr append } ;
>> allow domain tmpfile : file { ioctl read getattr lock append } ;
>> allow gssd_t user_tmp_t : file { ioctl read write getattr lock append
>> open } ;
>> ET allow gssd_t user_tmp_type : file { ioctl read getattr lock open } ; [
>> gssd_read_tmp ]
>> ET allow gssd_t user_tmp_t : file { ioctl read write create getattr
>> setattr lock append unlink link rename open } ; [ gssd_read_tmp ]
>>
>> Turning on the gssd_read_tmp boolean would allow it to update the
>> Credential Cache.
> Hmm, refpol does not have that. I will make a patch and send it
> (although gssd_read_tmp is not that great of a name since it writes).
>
> Should the cred cache really be labelled user_tmp_t tho? Is having
> something like user_krb_t not a better idea?
>
> I am also going to test out the storing it in the kernels keyring (I was
> pointed towards that by tfirg on #selinux).
>
> -- Jason
Well as we move forward kerberos tickets are slowly moving off of /tmp
and either into /run/user ... Or into the kernel keyring.