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; :
Created attachment 618402 [details] File: type
Created attachment 618403 [details] File: hashmarkername
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?
(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.
Ok, this is definitely caused by pungi.
(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?
(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.
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?
Sorry I missed this also. pungi or mock should be creating /dev/null as a chr_file labeled null_device_t.
(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.
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?
(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.
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.
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.
(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.
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.
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?
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.
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.