Summary: SELinux is preventing /sbin/setfiles access to a leaked /tmp/tmpB7zxxV file descriptor. Detailed Description: [restorecon has a permissive type (setfiles_t). This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /tmp/tmpB7zxxV. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context unconfined_u:system_r:setfiles_t:s0 Target Context unconfined_u:object_r:initrc_tmp_t:s0 Target Objects /tmp/tmpB7zxxV [ file ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.82-18.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-21.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name leaks 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 3 First Seen Tue 08 Jun 2010 08:59:20 PM EDT Last Seen Tue 08 Jun 2010 08:59:20 PM EDT Local ID 5746f95f-7afc-4a43-8a17-acdca27efb29 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1276045160.562:32): avc: denied { read append } for pid=8914 comm="restorecon" path="/tmp/tmpB7zxxV" dev=dm-1 ino=167696 scontext=unconfined_u:system_r:setfiles_t:s0 tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1276045160.562:32): arch=c000003e syscall=59 success=yes exit=0 a0=1cb3870 a1=1cadc60 a2=1cb4320 a3=38 items=0 ppid=8816 pid=8914 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:setfiles_t:s0 key=(null) Hash String generated from leaks,restorecon,setfiles_t,initrc_tmp_t,file,read,append audit2allow suggests: #============= setfiles_t ============== allow setfiles_t initrc_tmp_t:file { read append };
This looks like a service is running as initrc_t and redirecting output to a tmp file. What is your output of the following command? # ps -eZ | grep initrc_t
Some context: currently funcd seems to not start up correctly on laptops with wireless connections. So I started it up manually. Once I did so, running ps -eZ|grep initrc_t yielded: unconfined_u:system_r:initrc_t:s0 2371 ? 00:00:00 funcd While I've since rebooted from when this cropped up, I think this is the reproduction recipe, because the AVC happened while I was doing a yum update via func. (func "*" call yumcmd update)
This is funcd redirecting stdout to a /tmp file. yum installs packages and postinstalls execute restorecon with its output redirected here. It can safely be ignored.
funcd should put its output in a system directory /var/log/funcd preferably, then this SELinux error would disappear. System processes should not be using /tmp, that is for users. /var/run or /var/log are for system processes.
It's capturing the output to a securely made tmpfile so it can then send that output back out across the wire to the calling overlord system. I can change the tmpdir func uses - but I'm not sure I understand why /tmp is not acceptable.
Well I have rules in SELinux that say all apps can append to logfiles that they inherit, so it makes it easier from a policy writing reason. But my main objection is around possible attack vectors, I don't like root processes writing into directories that Users have control over, I know you are using some form of randomization of the tmp, but why take the risk at all? Here is my blog on this from a few years ago. http://danwalsh.livejournal.com/11467.html
I don't mind changing the tmp path but I don't want those paths to survive a reboot and they ARE NOT log files. So they don't belong in /var/log /var/tmp/$daemon/? /var/run/$daemon/ I can deal with any of those just fine. Which one is least bothersome to selinux?
Then they should go in /var/run I will fix the policy to allow the access
hmm - okay - now I'm in a bit of a pinch -I just looked through for the tempfile calls we have in func and I cannot find anyplace where we still make the tempfiles in /tmp - only in /var/lib/func can you tell me what version of func this is? thanks
*** Bug 610521 has been marked as a duplicate of this bug. ***
I got a duplicate of this, and bug 610521 (and bug 610527) happened at the same and references the same temp file but with a different tool, so I guess they have the same cause and are more or less duplicates.
Mads, so you're seeing the same thing from another app....
(In reply to comment #12) > so you're seeing the same thing from another app.... Yes and no and I don't know. setroubleshooter reported a duplicate, and it was the same "app" /sbin/setfiles, but apparently not related to the "func" app. The other two I marked as duplicates reported the same tmp file as the setroubleshooten one.
func-0.25-2.fc12.noarch
I've also experienced this. I just installed F13 x86_64 on this laptop and during the install of updates for the first time, I received this error many times. HOWEVER, I have not made -any- changes to the SELinux policies. I literally booted, installed flash through nspluginwrapper, and started downloading updates. I rebooted after yum updated so the rest of the updates could come through and about halfway through the update process is when I started receiving these denials from SE
After reboot, I received the popup again, so I ran the following: [tom@tom ~]$ ps -eZ |grep initrc system_u:system_r:initrc_t:s0-s0:c0.c1023 2181 ? 00:00:00 packagekitd [tom@tom ~]$
Wouw. A lot of CCs are popping up here - and even more on bug 610521 and bug 610527 . It looks like we found one (or several) bugs while in updates-testing, didn't figure out which update caused it, and now is has been promoted to updates.
That went on during the update immediate after the installation. My machine is Intel P45 with Nvidia PCI-E GC.
That went on during the last update (from 08.july.2010) immediate after install Fedora 13 on my computer - absolutely the same 4 bugs as these in comment 2 of Bug 610527: https://bugzilla.redhat.com/show_bug.cgi?id=610527. My machine is Intel P45 with Nvidia PCI-E GC.
I think this is not func but something happening during package install? could this be related to rpm/yum/selinux?
(In reply to comment #16) > After reboot, I received the popup again, so I ran the following: > > [tom@tom ~]$ ps -eZ |grep initrc > system_u:system_r:initrc_t:s0-s0:c0.c1023 2181 ? 00:00:00 packagekitd > [tom@tom ~]$ # rpm -q PackageKit PackageKit-0.6.6-1.fc13.x86_64 This version of PackageKit requires the following workaround for now chcon -t rpm_exec_t /usr/libexec/packagekitd I will update policy today.
So this turns out to be a duplicate of bug 612327 ? (Problem was only seen with PackageKit - never directly with yum.)
After installing all updates, I stopped having this issue.
*** This bug has been marked as a duplicate of bug 612327 ***