Bug 607399 - SELinux is preventing /sbin/setfiles access to a leaked /tmp/tmpB7zxxV file descriptor.
SELinux is preventing /sbin/setfiles access to a leaked /tmp/tmpB7zxxV file d...
Status: CLOSED DUPLICATE of bug 612327
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:7258d033c18...
:
: 610521 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-23 22:10 EDT by Scott Schmit
Modified: 2014-01-21 18:15 EST (History)
31 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-14 08:42:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Schmit 2010-06-23 22:10:36 EDT
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 };
Comment 1 Miroslav Grepl 2010-06-24 03:32:04 EDT
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
Comment 2 Scott Schmit 2010-06-24 06:51:23 EDT
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)
Comment 3 Daniel Walsh 2010-06-25 14:31:42 EDT
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.
Comment 4 Daniel Walsh 2010-06-25 14:34:23 EDT
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.
Comment 5 seth vidal 2010-06-25 14:48:16 EDT
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.
Comment 6 Daniel Walsh 2010-06-25 15:44:45 EDT
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
Comment 7 seth vidal 2010-06-25 15:51:37 EDT
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?
Comment 8 Daniel Walsh 2010-06-28 11:11:49 EDT
Then they should go in /var/run

I will fix the policy to allow the access
Comment 9 seth vidal 2010-06-28 11:26:47 EDT
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
Comment 10 Mads Kiilerich 2010-07-02 05:57:19 EDT
*** Bug 610521 has been marked as a duplicate of this bug. ***
Comment 11 Mads Kiilerich 2010-07-02 05:58:13 EDT
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.
Comment 12 seth vidal 2010-07-02 10:06:10 EDT
Mads,
 so you're seeing the same thing from another app....
Comment 13 Mads Kiilerich 2010-07-02 11:20:27 EDT
(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.
Comment 14 Scott Schmit 2010-07-02 15:12:13 EDT
func-0.25-2.fc12.noarch
Comment 15 Thomas Spear 2010-07-08 17:52:56 EDT
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
Comment 16 Thomas Spear 2010-07-08 18:03:06 EDT
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 ~]$
Comment 17 Mads Kiilerich 2010-07-10 06:19:37 EDT
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.
Comment 18 Filip Hristov 2010-07-12 21:41:00 EDT
That went on during the update immediate after the installation.
My machine is Intel P45 with Nvidia PCI-E GC.
Comment 19 Filip Hristov 2010-07-12 22:23:24 EDT
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.
Comment 20 seth vidal 2010-07-12 23:07:55 EDT
I think this is not func but something happening during package install? could this be related to rpm/yum/selinux?
Comment 21 Miroslav Grepl 2010-07-13 03:06:11 EDT
(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.
Comment 22 Mads Kiilerich 2010-07-13 07:12:54 EDT
So this turns out to be a duplicate of bug 612327 ?

(Problem was only seen with PackageKit - never directly with yum.)
Comment 23 Fred Laderoute 2010-07-13 20:27:12 EDT
After installing all updates, I stopped having this issue.
Comment 24 Daniel Walsh 2010-07-14 08:42:34 EDT

*** This bug has been marked as a duplicate of bug 612327 ***

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