Bug 573111 - Mock environment needs to fake chroot into thinking SELinux is disabled.
Summary: Mock environment needs to fake chroot into thinking SELinux is disabled.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-12 20:59 UTC by Daniel Walsh
Modified: 2019-08-19 14:33 UTC (History)
11 users (show)

Fixed In Version: mock-1.1.10-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 04:38:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2010-03-12 20:59:40 UTC
Description of problem:

Comment 1 Daniel Walsh 2010-03-12 21:02:44 UTC
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 10:05:22 UTC
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 14:46:10 UTC
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 21:34:55 UTC
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 22:19:48 UTC
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 12:39:36 UTC
Or can we add an option to Yum to say, don't put down labels.

Comment 7 Clark Williams 2010-08-21 12:57:45 UTC
So where are we on this bug?

Comment 8 Jan Vcelak 2010-08-23 06:44:49 UTC
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 20:57:11 UTC
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-15 03:23:15 UTC
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 15:41:02 UTC
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 15:41:33 UTC
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 15:43:40 UTC
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 15:46:04 UTC
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 05:56:07 UTC
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 22:21:44 UTC
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 20:58:15 UTC
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 16:13:48 UTC
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 20:03:58 UTC
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-20 02:26:08 UTC
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-20 02:29:19 UTC
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-20 02:32:12 UTC
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-20 02:35:05 UTC
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 08:24:44 UTC
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 08:33:40 UTC
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 14:36:37 UTC
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 15:13:08 UTC
(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 05:24:45 UTC
(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 07:57:34 UTC
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 16:08:12 UTC
(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 13:49:59 UTC
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 20:32:06 UTC
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 20:37:13 UTC
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 20:41:25 UTC
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 20:45:38 UTC
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 20:49:52 UTC
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-14 00:02:04 UTC
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 04:33:37 UTC
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-25 02:40:56 UTC
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-25 03:15:26 UTC
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 19:05:05 UTC
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 19:15:10 UTC
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.