From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Kerberized NFS
Date: Mon, 14 Jul 2014 07:10:55 -0400 [thread overview]
Message-ID: <53C3BABF.3090405@redhat.com> (raw)
In-Reply-To: <20140712104048.GA22561@pippin.Home>
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
next prev parent reply other threads:[~2014-07-14 11:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-12 10:41 [refpolicy] Kerberized NFS Jason Zaman
2014-07-14 11:10 ` Daniel J Walsh [this message]
2014-07-20 12:39 ` Jason Zaman
2014-07-22 18:13 ` Daniel J Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53C3BABF.3090405@redhat.com \
--to=dwalsh@redhat.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.