Bug 861281 - SELinux is preventing /usr/sbin/useradd from 'write' accesses on the file /dev/null.
SELinux is preventing /usr/sbin/useradd from 'write' accesses on the file /de...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
17
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
abrt_hash:1fd377e4c768db22fb85d65482e...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-28 00:40 EDT by Renich Bon Ciric
Modified: 2013-07-31 19:48 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 19:48:08 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)
File: type (9 bytes, text/plain)
2012-09-28 00:40 EDT, Renich Bon Ciric
no flags Details
File: hashmarkername (14 bytes, text/plain)
2012-09-28 00:40 EDT, Renich Bon Ciric
no flags Details

  None (edit)
Description Renich Bon Ciric 2012-09-28 00:40:17 EDT
Additional info:
libreport version: 2.0.13
kernel:         3.5.4-1.fc17.x86_64

description:
:SELinux is preventing /usr/sbin/useradd from 'write' accesses on the file /dev/null.
:
:*****  Plugin leaks (86.2 confidence) suggests  ******************************
:
:If you want to ignore useradd trying to write access the null file, because you believe it should not need this access.
:Then you should report this as a bug.  
:You can generate a local policy module to dontaudit this access.
:Do
:# grep /usr/sbin/useradd /var/log/audit/audit.log | audit2allow -D -M mypol
:# semodule -i mypol.pp
:
:*****  Plugin catchall (14.7 confidence) suggests  ***************************
:
:If you believe that useradd should be allowed write access on the null file by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:Do
:allow this access for now by executing:
:# grep useradd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023
:Target Context                unconfined_u:object_r:device_t:s0
:Target Objects                /dev/null [ file ]
:Source                        useradd
:Source Path                   /usr/sbin/useradd
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           shadow-utils-4.1.4.3-14.fc17.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-149.fc17.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.5.4-1.fc17.x86_64 #1 SMP Mon Sep
:                              17 15:03:59 UTC 2012 x86_64 x86_64
:Alert Count                   8
:First Seen                    2012-09-27 22:03:36 CDT
:Last Seen                     2012-09-27 23:34:50 CDT
:Local ID                      11ae8b0b-6a2f-4a7b-bd70-fe5475cb7c96
:
:Raw Audit Messages
:type=AVC msg=audit(1348806890.767:435): avc:  denied  { write } for  pid=26654 comm="usermod" path="/dev/null" dev="dm-2" ino=169214669 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:device_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1348806890.767:435): arch=x86_64 syscall=execve success=yes exit=0 a0=24d24f0 a1=24ce6b0 a2=24ce3d0 a3=7fff88280310 items=0 ppid=26633 pid=26654 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm=usermod exe=/usr/sbin/usermod subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null)
:
:Hash: useradd,useradd_t,device_t,file,write
:
:audit2allow
:
:#============= useradd_t ==============
:allow useradd_t device_t:file write;
:
:audit2allow -R
:
:#============= useradd_t ==============
:allow useradd_t device_t:file write;
:
Comment 1 Renich Bon Ciric 2012-09-28 00:40:20 EDT
Created attachment 618402 [details]
File: type
Comment 2 Renich Bon Ciric 2012-09-28 00:40:22 EDT
Created attachment 618403 [details]
File: hashmarkername
Comment 3 Daniel Walsh 2012-10-01 10:49:27 EDT
You have serious labeling probelems in /dev?

restorecon -R -v /dev

Should clean this up, but systemd should have done this for you.

What were you doing when you saw this?
Comment 4 Renich Bon Ciric 2012-10-02 21:49:01 EDT
(In reply to comment #3)
> You have serious labeling probelems in /dev?
> 
> restorecon -R -v /dev
> 
> Should clean this up, but systemd should have done this for you.
> 
> What were you doing when you saw this?

This is really strange. I do relabels every once in a while (2 or 3 a month)

I was using pungi to generate a tree as a normal user.
Comment 5 Miroslav Grepl 2012-10-04 05:22:36 EDT
Ok, this is definitely caused by pungi.
Comment 6 Spencer Shimko 2012-10-17 16:12:35 EDT
(In reply to comment #5)
> Ok, this is definitely caused by pungi.

I am encountering the same issue.  What makes you think it is pungi?  Pungi doesn't do much except wrap the anaconda runtime pieces that do the grunt work.  I've traced it back a bit but I can't find the source.  

1. Pungi runs /usr/lib/anaconda-runtime/buildinstall
2. That eventually runs /usr/lib/anaconda-runtime/upd-instroot
3. /usr/lib/anaconda-runtime/upd-instroot:
   - It empties $YUMDIR prior via rm -rf so at this point the tree is completely empty.  
   - It runs expandPackageSet which runs yum with --installroot=$YUMDIR.
   - .... and /dev inside that root is mislabeled.

IIUC upd-instroot cleans the whole tree and repopulates it all in one fail swoop.  
But nothing is creating /dev in that code.  Who is actually creating /dev in $YUMDIR?  I assume yum correct? So wouldn't it be a bug in yum itself?
Comment 7 Spencer Shimko 2012-10-17 16:25:48 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Ok, this is definitely caused by pungi.
> 
> I am encountering the same issue.  What makes you think it is pungi?  Pungi
> doesn't do much except wrap the anaconda runtime pieces that do the grunt
> work.  I've traced it back a bit but I can't find the source.  
> 
> 1. Pungi runs /usr/lib/anaconda-runtime/buildinstall
> 2. That eventually runs /usr/lib/anaconda-runtime/upd-instroot
> 3. /usr/lib/anaconda-runtime/upd-instroot:
>    - It empties $YUMDIR prior via rm -rf so at this point the tree is
> completely empty.  
>    - It runs expandPackageSet which runs yum with --installroot=$YUMDIR.
>    - .... and /dev inside that root is mislabeled.
> 
> IIUC upd-instroot cleans the whole tree and repopulates it all in one fail
> swoop.  
> But nothing is creating /dev in that code.  Who is actually creating /dev in
> $YUMDIR?  I assume yum correct? So wouldn't it be a bug in yum itself?

I apologize I see this is filed against F17.  I'm on RHEL 6.2.  Given the similarities I'm fairly certain there is a common source for this issue in both versions though.  LMK if you want me to open a separate bug.
Comment 8 Spencer Shimko 2012-10-17 16:40:54 EDT
Sorry for the barrage of updates but found something else interesting.  The object class involved is actually file, not chr_file.  Looks like the node isn't created at all.  So when an RPM writes to /dev/null from the %post it is creating a *file* which inherits device_t as the type.  Should yum be populating /dev?
Comment 9 Daniel Walsh 2012-10-26 14:58:54 EDT
Sorry I missed this also.  pungi or mock should be creating /dev/null as a chr_file labeled null_device_t.
Comment 10 Spencer Shimko 2012-12-13 12:47:45 EST
(In reply to comment #9)
> Sorry I missed this also.  pungi or mock should be creating /dev/null as a
> chr_file labeled null_device_t.

Dan, sorry been tracking the RHN support request and started ignoring this BZ.  The problem isn't in pungi.  It also isn't in mock.  They are just calling yum.  The problem is in yum and/or the fact that no RPM provides /dev/null.  Requiring udev in your spec to use /dev/null in a post is the wrong solution since /dev/null actually exists even without udev being up and running.

If someone could point me to an RPM that provides /dev/null I'll shut up.
Comment 11 Daniel Walsh 2012-12-17 15:41:43 EST
I would think it is up2 these tools to create the devices required in /dev and then to label them correctly if SELinux is enabled.

Is pungi creating other devices?
Comment 12 Spencer Shimko 2012-12-17 15:55:04 EST
(In reply to comment #11)
> I would think it is up2 these tools to create the devices required in /dev
> and then to label them correctly if SELinux is enabled.
> 
> Is pungi creating other devices?

Pungi isn't doing anything.  Yum is the "culprit."  Pungi is calling Anaconda's build-install which runs yum which triggers this problem.  Pungi and Anaconda should be removed as sources of this issue.  It is either yum or the lack of an RPM providing a basic /dev tree that is causing the problem.  Or maintainers using dev nodes in their %post.
Comment 13 Spencer Shimko 2012-12-17 16:06:19 EST
I should add that this is not only an SELinux issue.  SELinux just identified it :)  

Any maintainer using dev nodes in their %post should be concerned.  Any use of standard dev nodes in %post could lead to unexpected behavior if yum is used with the installroot option.
Comment 14 Daniel Walsh 2012-12-17 16:21:01 EST
According to the Anaconda team this has all been changed in F18, and I think we should concentrate on making sure that works correctly.  I personally believe that everything that happens in these environments should be confined on the outside but everything inside whould have the same label.  This is the way mock now works.  You end up allowing mock_t to write mock_lib_t and that is it.  Then we can control that mock_t can not use the network and we can use MCS separation to ensure two mock environments can not bother each other.
Comment 15 Spencer Shimko 2012-12-17 16:34:35 EST
(In reply to comment #14)
> According to the Anaconda team this has all been changed in F18, and I think
> we should concentrate on making sure that works correctly.  I personally
> believe that everything that happens in these environments should be
> confined on the outside but everything inside whould have the same label. 
> This is the way mock now works.  You end up allowing mock_t to write
> mock_lib_t and that is it.  Then we can control that mock_t can not use the
> network and we can use MCS separation to ensure two mock environments can
> not bother each other.

Understood and I agree on the access control parts of that statement but that does not address the underlying problem.  What do I add to a "Requries:" line to make sure /dev/null is present when my %post runs?  udev?  That hardly seems appropriate given the fact /dev/null exists without udev.

This could be seen as a security issue.  If a package maintainer uses /dev/null to redirect sensitive data, under the assumption is actually is the trusted null device, they could be surprised to find that their data now exists in a normal file on the filesystem.

Again, I'll shut-up and move along if someone will just tell me what I need to "Require:" to get a /dev/null node. No, udev isn't the answer to this question.  Unless it starts listing /dev/null in the %file section.
Comment 16 Daniel Walsh 2012-12-18 09:53:08 EST
Any tool that creates a chroot directory is required to setup an appropriate /dev or mount the /dev from outside the chroot inside the chroot.  I am not sure if this is Mock/pungi or lorax.
Comment 17 Spencer Shimko 2013-01-03 10:39:18 EST
In this case it isn't a proper chroot (afaik).  It is a directory generated by anaconda which is later rolled up using mkisofs. I don't think you can configure it either (I see this in the anaconda code): 

YUMDIR=${TMPDIR:-/tmp}/yumdir.$$
mkdir -p $YUMDIR/var/log
mkdir -p $YUMDIR/var/lib/yum

That means tools that leverage anaconda can't control that path.

In the end I don't think it being a chroot matters.  Whatever is creating the directory prior to running yum installroot should handle it right?  Anaconda buildinstall already seems to be handling populating the directory with some subdirs.  Should it be the one mounting the pseudo-filesystems as well?
Comment 18 Fedora End Of Life 2013-07-03 18:08:40 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2013-07-31 19:48:12 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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