Bug 599036

Summary: SELinux is preventing /usr/sbin/rpc.svcgssd "unlink" access on nfs_0.
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: dwalsh, mgrepl, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:18aac159d226d546ad455ecc22f1ed138e907cb3daf8b1ca4d24b641a3a94326
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-02 17:27:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Layton 2010-06-02 14:57:38 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                system_u:system_r:gssd_t:s0
Target Context                unconfined_u:object_r: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.2-2.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-21.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.33.5-112.fc13.x86_64 #1 SMP Thu May 27
                              02:28:31 UTC 2010 x86_64 x86_64
Alert Count                   119
First Seen                    Thu 13 May 2010 09:49:34 PM EDT
Last Seen                     Wed 02 Jun 2010 10:50:55 AM EDT
Local ID                      ddca5df2-ac72-4289-a871-24322948b310
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1275490255.724:8): avc:  denied  { unlink } for  pid=2804 comm="rpc.svcgssd" name="nfs_0" dev=dm-0 ino=2397967 scontext=system_u:system_r:gssd_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1275490255.724:8): arch=c000003e syscall=87 success=no exit=-13 a0=7f22a5018800 a1=0 a2=0 a3=7fffd3fb7e60 items=0 ppid=2803 pid=2804 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rpc.svcgssd" exe="/usr/sbin/rpc.svcgssd" subj=system_u:system_r:gssd_t:s0 key=(null)



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

#============= gssd_t ==============
allow gssd_t tmp_t:file unlink;
Comment 1 Jeff Layton 2010-06-02 14:58:27 UTC 
Looks like it's preventing rpc.svcgssd from unlinking /var/tmp/nfs_0
Comment 2 Daniel Walsh 2010-06-02 15:26:34 UTC 
Jeff do you know what process created nfs_0?
Comment 3 Jeff Layton 2010-06-02 15:43:01 UTC 
No, I'm not sure. Here's the stat output in case it helps:

[jlayton@tlielax ~]$ stat -Z /var/tmp/nfs_0 
  File: `/var/tmp/nfs_0'
  Size: 6         	Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d	Inode: 2397967     Links: 1     Device type: 0,0
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
   S_Context: unconfined_u:object_r:tmp_t:s0
Access: 2010-05-26 18:10:50.044771307 -0400
Modify: 2010-03-02 06:34:42.000000000 -0500
Change: 2010-05-26 19:56:24.551863862 -0400
Comment 4 Daniel Walsh 2010-06-02 15:58:48 UTC 
Jeff if you remove this file by hand and then connect again, what is the label on the file.

ls -lZ /var/tmp/nfs_0
Comment 5 Daniel Walsh 2010-06-02 16:00:06 UTC 
If it is created by rpc.svcgssd
Comment 6 Jeff Layton 2010-06-02 16:34:28 UTC 
Removing the file allowed it to start and it did recreate the file:

$ stat -Z /var/tmp/nfs_0 
  File: `/var/tmp/nfs_0'
  Size: 6         	Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d	Inode: 2397967     Links: 1     Device type: 0,0
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
   S_Context: unconfined_u:object_r:gssd_tmp_t:s0
Access: 2010-06-02 12:30:38.856400789 -0400
Modify: 2010-06-02 12:30:39.081451151 -0400
Change: 2010-06-02 12:30:39.081451151 -0400

...hmm -- I did run restorecon -R on the root filesystem of this box not too long ago so that's may be the root cause here.

It does seem like the policy should deal with that possibility though.
Comment 7 Daniel Walsh 2010-06-02 17:27:36 UTC 
The file got created with the expected context this time.  gssd_tmp_t, rather then tmp_t.  Which was unexpected.  I have no idea how it could have been created with that context unless the kernel or a process on an without transition rules in a permissive machine.

Anyways reopen if it happens again.
Comment 8 Jeff Layton 2010-06-02 17:39:14 UTC 
Sounds good. The current policy seems to be correct AFAICT:

$ sudo restorecon /var/tmp/nfs_0
$ ls -Z /var/tmp/nfs_0
-rw-------. root root unconfined_u:object_r:gssd_tmp_t:s0 /var/tmp/nfs_0

Which is correct. Maybe I got bitten by a busted policy at some point.

Weird.