From: jason@perfinion.com (Jason Zaman)
Date: Sun, 20 Jul 2014 16:39:43 +0400
Subject: [refpolicy] Kerberized NFS
In-Reply-To: <53C3BABF.3090405@redhat.com>
References: <20140712104048.GA22561@pippin.Home> <53C3BABF.3090405@redhat.com>
Message-ID: <20140720123943.GA31539@pippin.perfinion.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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