Description of problem:
Oops here is the description. Easy to fake SELinux out. Mock currently mounts /proc in to MOCKPATH/proc Needs to also grep -v selinuxfs /proc/filesystem > /var/run/mock/fakefilesys mount -o bind /var/run/mock/fakefilesystem MOCKPATH/proc/filesystem Then all processes run within mock will think SELinux is disabled. Second faze is to tell rpm/yum to NOT put down labels. These changes would allow us to safely write policy to run on an enforcing SELinux system.
Rpm will automatically skip labeling if is_selinux_enabled() returns false, so IF the bind-mount trick achieves that then it should "just work". Otherwise yum will need a way to set RPMTRANS_FLAG_NOCONTEXTS transaction flag (which was missing in the python bindings until about just now...) If this is needed in koji then that's a bit uglier as the builders are running a custom-built rpm-4.6.0 where the RPMTRANS_FLAG_NOCONTEXTS is not in python bindings, so yum would need to use its value instead (1 << 8) for tsflags.
is_selinux_enabled outside of the chroot will return 1, inside the chroot it returns 0. I think rpm runs outside the chroot, I believe, so it will see that SELinux is enabled, and will put down labels. If python allows the passing of RPMTRANS_FLAG_NOCONTEXTS, then we want mock to set this flag. This will allow me to write rules that isolate one mock environemnt from another and we can decide things like whether or not we want mock to be allowed to connect to the network and will definitely prevent mock from attacking the host machine or any other mock instances.
Yes, rpm is ran outside, so yes, mock will have to influence yum to influence this setting. Whee what fun!
So how are we going to do that (since we shell out to run yum)? Is there an environment variable that yum or rpm pays attention to?
Or can we add an option to Yum to say, don't put down labels.
So where are we on this bug?
Both suggestions are implemented in current selinux plugin. http://git.fedorahosted.org/git/?p=mock.git;a=blob;f=py/mock/plugins/selinux.py > Mock currently mounts /proc in to MOCKPATH/proc > Needs to also > grep -v selinuxfs /proc/filesystem > /var/run/mock/fakefilesys > mount -o bind /var/run/mock/fakefilesystem MOCKPATH/proc/filesystem This is done. > Or can we add an option to Yum to say, don't put down labels. This is done if yum supports --setopt (-setopt=tsflags=nocontexts).
Could this be related to my bug #630479? My root.log does show that nocontexts is set: DEBUG util.py:294: Executing command: /usr/bin/yum --installroot /var/lib/mock/fedora-13-i386/root/ update --setopt=tsflags=nocontexts but I still get the selinux error as described in that bug.
New version of mock (mock-1.1.6) available in koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=200570 Please try it out and see if it fixes (or changes) your problem.
mock-1.1.6-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc13
mock-1.1.6-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc14
mock-1.0.13-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.13-1.el5
mock-1.0.13-1.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/mock-1.0.13-1.fc12
mock-1.1.6-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mock'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc13
mock-1.1.6-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.6-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.0.14-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.14-1.el5
mock-1.0.15-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.15-1.el5
mock-1.1.9-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/mock-1.1.9-1.fc13
mock-1.0.16-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.16-1.el5
mock-1.1.9-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.9-1.el6
mock-1.1.9-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mock-1.1.9-1.fc14
mock-1.1.9-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.9-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately this bug is not entirely fixed, as can be seen when trying to rebuild coreutils in a chroot (I tried with epel 6 and Fedora 15 chroot). There are a number of situations to consider. 1. running moch --rebuild ------------------------- In this case, selinux is grepped out of /proc/filesystems, but unfortunately the files still have a context. The coreutils unit tests do "ls -Zd ." to check if selinux is enabled: If the output is ?, then they assume selinux is disabled, else they think it's enabled. And unfortunately, the output is the file listing (well, only the current directory) with its context. The way the unit tests detect whether selinux is running is probably not very smart, but still, selinux is not properly faked off. So if this updates hits stable (and it's updated on the Koji builders), this will effectively prevent from building coreutils on Koji, and probably other packages. 2. running mock --shell ----------------------- This time, selinux is not even grepped out of /proc/filesystems. Is that expected? Shouldn't the behavior of the shell be consistent with the behavior of the rebuild? If they are not, it makes the shell much less useful to debug build failures.
(In reply to comment #26) > Unfortunately this bug is not entirely fixed, as can be seen when trying to > rebuild coreutils in a chroot (I tried with epel 6 and Fedora 15 chroot). > > There are a number of situations to consider. > > 1. running moch --rebuild > ------------------------- > In this case, selinux is grepped out of /proc/filesystems, but unfortunately > the files still have a context. The coreutils unit tests do "ls -Zd ." to check > if selinux is enabled: > > If the output is ?, then they assume selinux is disabled, else they think it's > enabled. And unfortunately, the output is the file listing (well, only the > current directory) with its context. > > The way the unit tests detect whether selinux is running is probably not very > smart, but still, selinux is not properly faked off. > And honestly, I don't see anything else we can do. I don't see any good way to have SELinux enabled on the host system and truly disabled inside the chroot. Admittedly I'm not an SELinux expert, but I think you're talking some truly invasive kernel changes to attempt something like that. Can you change the test from doing an ls -Zd to looking for selinux in /proc/filesystems? > So if this updates hits stable (and it's updated on the Koji builders), this > will effectively prevent from building coreutils on Koji, and probably other > packages. No, it won't because the Koji builders run with SELinux turned off. > > 2. running mock --shell > ----------------------- > > This time, selinux is not even grepped out of /proc/filesystems. > > Is that expected? Shouldn't the behavior of the shell be consistent with the > behavior of the rebuild? > > If they are not, it makes the shell much less useful to debug build failures. Good point. We need to look at running plugins around invoking the shell.
(In reply to comment #27) > (In reply to comment #26) > > Unfortunately this bug is not entirely fixed, as can be seen when trying to > > rebuild coreutils in a chroot (I tried with epel 6 and Fedora 15 chroot). [... snip ...] > > The way the unit tests detect whether selinux is running is probably not very > > smart, but still, selinux is not properly faked off. > > And honestly, I don't see anything else we can do. I don't see any good way to > have SELinux enabled on the host system and truly disabled inside the chroot. > Admittedly I'm not an SELinux expert, but I think you're talking some truly > invasive kernel changes to attempt something like that. I'm not an expert either, but maybe the reporter of the original bug might have an idea? :] > Can you change the test from doing an ls -Zd to looking for selinux in > /proc/filesystems? I just sent a patch upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8359 I also opened bug reports for Fedora and RHEL6 (with a backported patch for the latter). > > 2. running mock --shell > > ----------------------- > > > > This time, selinux is not even grepped out of /proc/filesystems. > > > > Is that expected? Shouldn't the behavior of the shell be consistent with the > > behavior of the rebuild? > > > > If they are not, it makes the shell much less useful to debug build failures. > > Good point. We need to look at running plugins around invoking the shell. Would you like a separate bug report for this?
Thank you for the report. I replied on the upstream list: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22135 (or http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8359#8)
(In reply to comment #28) > > > > Good point. We need to look at running plugins around invoking the shell. > > Would you like a separate bug report for this? I was just reminded that I have this fix in my queue already (an updated selinux plugin). So no I think we'll just have this when 1.1.10 comes out.
changes are available in my git 'work' branch. queued for 1.1.10/1.0.17 build for next week.
mock-1.1.10-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc15
mock-1.1.10-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc14
mock-1.0.17-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.17-1.el5
mock-1.1.10-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc13
mock-1.1.10-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.10-1.el6
Package mock-1.1.10-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.1.10-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/mock-1.1.10-1.el6 then log in and leave karma (feedback).
mock-1.1.10-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.10-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.10-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.0.17-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.10-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.