Bug 599036 - 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.
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy   
(Show other bugs)
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:18aac159d22...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-02 14:57 UTC by Jeff Layton
Modified: 2010-06-02 17:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-02 17:27:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jeff Layton 2010-06-02 14:57:38 UTC

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

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)
                     #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.


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