Bug 626367

The problem is /dev/null is mislabeled.

Is udev running with the correct context?

# ps -eZ | grep udev


# restorecon -v /dev/null 

Will fix the label, but udev should have done this by default.

(In reply to comment #1)
> The problem is /dev/null is mislabeled.
> 
> Is udev running with the correct context?
> 
> # ps -eZ | grep udev

[root@auto-i386-001 ~]# ps -eZ | grep udev
system_u:system_r:udev_t:s0-s0:c0.c1023 462 ?  00:00:00 udevd

> 
> # restorecon -v /dev/null 

No changes made.

> 
> Will fix the label, but udev should have done this by default.

looks like the context is OK now

# ls -Z /dev/null

(In reply to comment #3)
> looks like the context is OK now
> 
> # ls -Z /dev/null

[root@auto-i386-001 ~]# ls -Z /dev/null
crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null

It is ok. Could you try to re-run your tests and then execute

ausearch -m avc -ts recent

(In reply to comment #5)
> It is ok. Could you try to re-run your tests and then execute
> 
> ausearch -m avc -ts recent

# make run ; ausearch -m avc -ts recent

...

----
time->Mon Aug 23 15:15:18 2010
type=SYSCALL msg=audit(1282590918.514:45890): arch=40000003 syscall=11 success=yes exit=0 a0=8ae01a8 a1=8ade8d8 a2=8ade6a0 a3=8ade8d8 items=0 ppid=28553 pid=28554 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=98 comm="groupadd" exe="/usr/sbin/groupadd" subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1282590918.514:45890): avc:  denied  { write } for  pid=28554 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851136 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file
type=AVC msg=audit(1282590918.514:45890): avc:  denied  { write } for  pid=28554 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851136 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file

Looks like tests handle with /dev/null.

Does the test delete /dev/null or is the test running a rpm install within a chroot environment?

I have discovered that the aforementioned AVC are produced by the following command (consider this to be new reproducer):

# yum --installroot=<some_dir> -y install <some_package>
...

# ausearch -m avc -ts recent
----
time->Mon Aug 23 15:52:51 2010
type=SYSCALL msg=audit(1282593171.418:45941): arch=40000003 syscall=11 success=yes exit=0 a0=9d9c1a8 a1=9d9a8d8 a2=9d9a6a0 a3=9d9a8d8 items=0 ppid=28934 pid=28935 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=98 comm="groupadd" exe="/usr/sbin/groupadd" subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1282593171.418:45941): avc:  denied  { write } for  pid=28935 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851141 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file
type=AVC msg=audit(1282593171.418:45941): avc:  denied  { write } for  pid=28935 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851141 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file

Honestly, I do not know how yum works when using --installroot option, may be it really uses chroot environment.

We have an open bug on this in Fedora.  The problem is the install runs and labels things correctly except the /dev/ gets created without any actual devices.  When one of the post install scripts redirects the output to /dev/null, the FILE /dev/null gets created with the default context device_t rather then a device labeled null_device_t.  These AVC's can be ignored since the tools work correctly.

I do not have an easy fix for this except for RHEL6.  In fedora I am suggesting we adopt the changes we have put in for mock, where labels are not applied and rpm does not transition in the postinstalls.

Hmm, this sounds promisingly (i.e. no regression in yum/rpm). Thanks for your clarification. So this seems to be more or less a real bug of selinux-policy, right?

I would argue in yum/rpm  But it is a real bug... :^)

Dan, Panu, should this move to the selinux component?

It's not really clear whose bug this is :)

If the point is just to avoid the selinux warnings then it can be avoided by disabling selinux labeling for the chroot install. Rpm has --nocontexts switch for this, and recent yum knows about it but IIRC doesn't have a cli-switch for enabling it. But rpm might need a further change to avoid running scripts in selinux contexts when --nocontexts is used (upstream rpm HEAD has this)

But to /really/ fix this... well, IMO this is a "package set" bug - since the packages depend on /dev/null existince, something should create that file. Rpm doesn't (and cannot) know what devices etc the package scriptlets might need. It would be possible for "filesystem" could create the bare minimum /dev bits like null, stdout, stderr, [u]random etc with a <lua> script, that should get /dev/null into existence sufficiently early in the common case (although not guaranteed) but I dunno whether that'd cause complications for udev and friends.

Or rpm could have a hook for populating empty chroot with distro-specific obligatory stuff, but this is pure scifi ATM, nothing of the sort exists in upstream.

Or maybe yum should setup the chroot environment.   SELinux is actually complaining about groupadd appending to a file named /dev/null, not a char file.

We could change SELinux policy to say files named /dev/null should be labeled null_device_t but then we would need to say something along the lines of everyone what can read/write null_device_t chr_file can read/write null_device_t file,  which is not something I want to allow.

yum should set up what in the chroot environment? yum doesn't do anything in particular inside chroots, it mostly leaves the paths to rpm to setup during the transaction. 

mock sets up a variety of things before creating a chroot. Is this a situation where the users case should use mock instead of yum?

I agree, mock also turns off labeling now so you want end up with a conflict between two different policies.

Of course I am not sure if that is in RHEL6 yet.

RHEL-6 GA yum has the nocontexts tsflag support. mock isn't in RHEL, FWIW the current epel-6 version (which is _beta_) is mock-1.1.5-1.el6.noarch.rpm.

And the tsflag options can be set from yum cmd line, via. --setopt.
So I'm going to close this unless Dan needs something else from yum?

Sounds good to me.