Bug 573111 - Mock environment needs to fake chroot into thinking SELinux is disabled.
Mock environment needs to fake chroot into thinking SELinux is disabled.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Clark Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-12 15:59 EST by Daniel Walsh
Modified: 2014-01-21 01:16 EST (History)
10 users (show)

See Also:
Fixed In Version: mock-1.1.10-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 00:38:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2010-03-12 15:59:40 EST
Description of problem:
Comment 1 Daniel Walsh 2010-03-12 16:02:44 EST
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.
Comment 2 Panu Matilainen 2010-03-16 06:05:22 EDT
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.
Comment 3 Daniel Walsh 2010-03-16 10:46:10 EDT
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.
Comment 4 Jesse Keating 2010-03-16 17:34:55 EDT
Yes, rpm is ran outside, so yes, mock will have to influence yum to influence this setting.  Whee what fun!
Comment 5 Clark Williams 2010-03-16 18:19:48 EDT
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?
Comment 6 Daniel Walsh 2010-03-17 08:39:36 EDT
Or can we add an option to Yum to say, don't put down labels.
Comment 7 Clark Williams 2010-08-21 08:57:45 EDT
So where are we on this bug?
Comment 8 Jan Vcelak 2010-08-23 02:44:49 EDT
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).
Comment 9 Alex Lancaster 2010-09-05 16:57:11 EDT
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.
Comment 10 Clark Williams 2010-10-14 23:23:15 EDT
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.
Comment 11 Fedora Update System 2010-10-20 11:41:02 EDT
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
Comment 12 Fedora Update System 2010-10-20 11:41:33 EDT
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
Comment 13 Fedora Update System 2010-10-20 11:43:40 EDT
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
Comment 14 Fedora Update System 2010-10-20 11:46:04 EDT
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
Comment 15 Fedora Update System 2010-10-21 01:56:07 EDT
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
Comment 16 Fedora Update System 2010-10-28 18:21:44 EDT
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.
Comment 17 Fedora Update System 2010-11-01 16:58:15 EDT
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.
Comment 18 Fedora Update System 2010-12-14 11:13:48 EST
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
Comment 19 Fedora Update System 2011-01-18 15:03:58 EST
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
Comment 20 Fedora Update System 2011-02-19 21:26:08 EST
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
Comment 21 Fedora Update System 2011-02-19 21:29:19 EST
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
Comment 22 Fedora Update System 2011-02-19 21:32:12 EST
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
Comment 23 Fedora Update System 2011-02-19 21:35:05 EST
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
Comment 24 Fedora Update System 2011-03-03 03:24:44 EST
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.
Comment 25 Fedora Update System 2011-03-03 03:33:40 EST
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.
Comment 26 Mathieu Bridon 2011-03-26 10:36:37 EDT
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.
Comment 27 Clark Williams 2011-03-26 11:13:08 EDT
(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.
Comment 28 Mathieu Bridon 2011-03-28 01:24:45 EDT
(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?
Comment 29 Jim Meyering 2011-03-28 03:57:34 EDT
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)
Comment 30 Clark Williams 2011-03-28 12:08:12 EDT
(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.
Comment 31 Clark Williams 2011-05-07 09:49:59 EDT
changes are available in my git 'work' branch. 

queued for 1.1.10/1.0.17 build for next week.
Comment 32 Fedora Update System 2011-05-13 16:32:06 EDT
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
Comment 33 Fedora Update System 2011-05-13 16:37:13 EDT
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
Comment 34 Fedora Update System 2011-05-13 16:41:25 EDT
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
Comment 35 Fedora Update System 2011-05-13 16:45:38 EDT
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
Comment 36 Fedora Update System 2011-05-13 16:49:52 EDT
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
Comment 37 Fedora Update System 2011-05-13 20:02:04 EDT
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).
Comment 38 Fedora Update System 2011-05-19 00:33:37 EDT
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.
Comment 39 Fedora Update System 2011-05-24 22:40:56 EDT
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.
Comment 40 Fedora Update System 2011-05-24 23:15:26 EDT
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.
Comment 41 Fedora Update System 2011-06-02 15:05:05 EDT
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.
Comment 42 Fedora Update System 2011-06-02 15:15:10 EDT
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.

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