Bug 655081 - SELinux is preventing /usr/sbin/rpc.svcgssd "unlink" access on nfs_0.
Summary: SELinux is preventing /usr/sbin/rpc.svcgssd "unlink" access on nfs_0.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:f827099b06d...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-19 15:00 UTC by Trond Myklebust
Modified: 2011-05-27 14:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-27 14:16:34 UTC
Type: ---


Attachments (Terms of Use)

Description Trond Myklebust 2010-11-19 15:00:12 UTC
Summary:

SELinux is preventing /usr/sbin/rpc.svcgssd "unlink" access on nfs_0.

Detailed Description:

SELinux denied access requested by rpc.svcgssd. It is not expected that this
access is required by rpc.svcgssd and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                unconfined_u:system_r:gssd_t:s0
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                nfs_0 [ file ]
Source                        rpc.svcgssd
Source Path                   /usr/sbin/rpc.svcgssd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           nfs-utils-1.2.3-1.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-10.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08
                              UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Fri 19 Nov 2010 09:58:39 AM EST
Last Seen                     Fri 19 Nov 2010 09:58:39 AM EST
Local ID                      2f5a44aa-3c8b-4cea-8ae4-4154833bacdc
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1290178719.765:130): avc:  denied  { unlink } for  pid=30010 comm="rpc.svcgssd" name="nfs_0" dev=dm-0 ino=1165095 scontext=unconfined_u:system_r:gssd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1290178719.765:130): arch=c000003e syscall=87 success=no exit=-13 a0=7fc7537af960 a1=0 a2=0 a3=7fff70b58b50 items=0 ppid=30009 pid=30010 auid=520 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="rpc.svcgssd" exe="/usr/sbin/rpc.svcgssd" subj=unconfined_u:system_r:gssd_t:s0 key=(null)



Hash String generated from  catchall,rpc.svcgssd,gssd_t,user_tmp_t,file,unlink
audit2allow suggests:

#============= gssd_t ==============
allow gssd_t user_tmp_t:file unlink;

Comment 1 Daniel Walsh 2010-11-19 15:22:15 UTC
Did you run rpc.svcgssd directly by hand?

Comment 2 Trond Myklebust 2010-11-19 18:12:49 UTC
Yes. That's where things get weird:

   Everything works fine when I run rpc.svcgssd by hand.
   Things also work when I run 'sh -x /etc/init.d/rpcsvcgssd start'.

However, just plain old '/etc/init.d/rpcsvcgssd start' leads to
[root@heimdal ~]# /etc/init.d/rpcsvcgssd start
Starting RPC svcgssd:                                      [FAILED]

and I get the above selinux AVC denial.

Comment 3 Daniel Walsh 2010-11-19 19:23:37 UTC
The file is mislabeled because you ran it by hand.

Remove the file and then run it via the script.

The service only runs confined if you run it via the service, if you run it by hand it stays as unconfined_t and creates the files in /var/tmp and /tmp as user_tmp_t.  If you run it via the service script it transitions to gssd_t and creates files with the correct label in /tmp and /var/tmp.  But it is not allowed to touch files labeled user_tmp_t.

Comment 4 Trond Myklebust 2010-11-19 19:33:21 UTC
That makes no difference:

[root@heimdal ~]# find /tmp -name \*nfs\*
[root@heimdal ~]# service rpcsvcgssd start
Starting RPC svcgssd:                                      [FAILED]
[root@heimdal ~]# find /tmp -name \*nfs\*

As you can see from the above, there doesn't actually appear to be a file named nfs_0 in /tmp (or any subdirs) either before or after I run the service.

Comment 5 Daniel Walsh 2010-11-19 19:43:56 UTC
Check /var/tmp

Comment 6 Trond Myklebust 2010-11-19 20:14:17 UTC
Ah... Found it... and yes, you're right it was mislabelled as user_tmp_t.

That said, it is not an easy issue to resolve if you are unfamiliar with
selinux, and it doesn't appear that the usual tools, such as
restorecon/restorecond, are able to fix it.
I see there is a rule for /var/tmp/host_0 in
/etc/selinux/targeted/contexts/files/file_contexts. Any chance we could
get one for /var/tmp/nfs_0 too?

Comment 7 Daniel Walsh 2010-11-19 20:39:37 UTC
Yes, what is it labeled when you start it the normal way. gssd_tmp_t?

Comment 8 Daniel Walsh 2010-11-19 20:41:15 UTC
Miroslav can you add 

/var/tmp/nfs_0 		 --	gen_context(system_u:object_r:gssd_tmp_t,s0)

I think it could be a bug in /usr/sbin/rpc.svcgssd that it is deleting this file at all.

Comment 9 Daniel Walsh 2010-11-19 20:42:24 UTC
Steve, Why is /var/tmp/nfs_0 being deleted?  Or is it just being rewritten because the cache is growing?

Comment 10 Daniel Walsh 2010-11-19 20:50:52 UTC
I don't think there is a bug in nfs, this is just the way the replay cache gets updated.

Comment 11 Trond Myklebust 2010-11-19 21:40:15 UTC
The normal label is indeed gssd_tmp_t.

I can't find anything in the nfs-utils code that appears to want to create
or unlink any files in /var/tmp, so I'm going to guess that this is something
the kerberos libraries are playing with. This would also explain why
/var/tmp/host_0 is labelled with a kerberos tag: krb5_host_rcache_t.

Comment 12 Miroslav Grepl 2010-11-22 09:58:52 UTC
Fixed in selinux-policy-3.9.7-13.fc14


Note You need to log in before you can comment on or make changes to this bug.