Bug 607399

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 ***