From: dwalsh@redhat.com (Daniel J Walsh)
Date: Tue, 22 Jul 2014 14:13:26 -0400
Subject: [refpolicy] Kerberized NFS
In-Reply-To: <20140720123943.GA31539@pippin.perfinion.com>
References: <20140712104048.GA22561@pippin.Home> <53C3BABF.3090405@redhat.com>
	<20140720123943.GA31539@pippin.perfinion.com>
Message-ID: <53CEA9C6.1020207@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com


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.