From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 14 Jul 2014 07:10:55 -0400
Subject: [refpolicy] Kerberized NFS
In-Reply-To: <20140712104048.GA22561@pippin.Home>
References: <20140712104048.GA22561@pippin.Home>
Message-ID: <53C3BABF.3090405@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com


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