[refpolicy] Kerberized NFS

[refpolicy] Kerberized NFS

[Jason Zaman]

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 

[refpolicy] Kerberized NFS

[Daniel J Walsh]

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 

[refpolicy] Kerberized NFS

[Jason Zaman]

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

[refpolicy] Kerberized NFS

[Daniel J Walsh]

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.