Bug 626367 - selinux is preventing groupadd write to /dev/null
selinux is preventing groupadd write to /dev/null
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: James Antill
BaseOS QE Security Team
:
Depends On: 624821 627266 629274
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-23 07:13 EDT by Ondrej Moriš
Modified: 2014-01-21 01:19 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-23 17:16:19 EST
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 Ondrej Moriš 2010-08-23 07:13:54 EDT
Description of problem:

First of all, I am not sure whether this is a bug or not. Running test [1] and [2] succeed, but the following AVC is produced:

type=SYSCALL msg=audit(1282561153.691:45416): arch=40000003 syscall=11 success=yes exit=0 a0=99e31a8 a1=99e18d8 a2=99e16a0 a3=99e18d8 items=0 ppid=13734 pid=13735 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=37 comm="groupadd" exe="/usr/sbin/groupadd" subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1282561153.691:45416): avc:  denied  { write } for  pid=13735 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851035 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(1282561153.691:45416): avc:  denied  { write } for  pid=13735 comm="groupadd" path="/dev/null" dev=dm-0 ino=1851035 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file

[1] /CoreOS/rpm/Regression/bz434150-rpm-root-malfunction
[2] /CoreOS/rpm/Regression/bz508074-rpm-Va-root-external-folder-fails-sometimes

Version-Release number of selected component (if applicable):

selinux-policy-3.7.19-40.el6
selinux-policy-targeted-3.7.19-40.el6
rpm-4.8.0-12.el6
yum-3.2.27-13.el6
RHEL6.0-20100818.0

How reproducible:

Always.

Steps to Reproduce:

1. Execute [1] or [2].
2. ausearch -m AVC -m USER_AVC -m SELINUX_ERR -ts recent
  
Actual results:

AVC pops up.

Expected results:

No AVC.

Additional info:

The aforementioned tests do not call groupadd explicitly, this command is probably called by rpm itself. If you think that selinux-policy behaves correctly in this case, I am ready to clone this bug for rpm.
Comment 1 Miroslav Grepl 2010-08-23 07:55:31 EDT
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.
Comment 2 Ondrej Moriš 2010-08-23 08:14:14 EDT
(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.
Comment 3 Miroslav Grepl 2010-08-23 08:21:22 EDT
looks like the context is OK now

# ls -Z /dev/null
Comment 4 Ondrej Moriš 2010-08-23 09:43:44 EDT
(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
Comment 5 Miroslav Grepl 2010-08-23 10:53:43 EDT
It is ok. Could you try to re-run your tests and then execute

ausearch -m avc -ts recent
Comment 6 Ondrej Moriš 2010-08-23 15:27:35 EDT
(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
Comment 7 Miroslav Grepl 2010-08-23 15:47:18 EDT
Looks like tests handle with /dev/null.
Comment 8 Daniel Walsh 2010-08-23 15:54:01 EDT
Does the test delete /dev/null or is the test running a rpm install within a chroot environment?
Comment 9 Ondrej Moriš 2010-08-23 16:04:13 EDT
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.
Comment 10 Daniel Walsh 2010-08-23 16:13:10 EDT
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.
Comment 11 Ondrej Moriš 2010-08-23 16:18:18 EDT
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?
Comment 12 Daniel Walsh 2010-08-23 16:20:42 EDT
I would argue in yum/rpm  But it is a real bug... :^)
Comment 14 Denise Dumas 2010-12-01 17:32:45 EST
Dan, Panu, should this move to the selinux component?
Comment 15 Panu Matilainen 2010-12-02 02:56:28 EST
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.
Comment 16 Daniel Walsh 2010-12-02 09:54:51 EST
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.
Comment 17 seth vidal 2010-12-02 10:24:25 EST
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?
Comment 18 Daniel Walsh 2010-12-02 10:37:40 EST
I agree, mock also turns off labeling now so you want end up with a conflict between two different policies.
Comment 19 Daniel Walsh 2010-12-02 10:38:01 EST
Of course I am not sure if that is in RHEL6 yet.
Comment 20 James Antill 2010-12-02 11:26:44 EST
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.
Comment 21 James Antill 2010-12-23 12:39:50 EST
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?
Comment 22 Daniel Walsh 2010-12-23 14:18:48 EST
Sounds good to me.

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