Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 981981

Summary: mock is not working from a confined user user in staff_u
Product: [Fedora] Fedora Reporter: Michael Scherer <misc>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 10:55:52 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Michael Scherer 2013-07-07 09:36:17 EDT
Trying to run mock ( for fedora-review ) as a confined user lead to several AVC :

when trying to clean the chroot :
type=AVC msg=audit(1373203400.371:10979): avc:  denied  { getattr } for  pid=5516 comm="mock" path="/usr/sbin/lvm" dev="dm-2" ino=1183245 scontext=staff_u:staff_r:mock_t:s0 tcontext=system_u:object_r:lvm_exec_t:s0 tclass=file


because mock remove the whole directory. Not sure if this should be set as dontaudit or if geattr should be autorized.



type=AVC msg=audit(1373203605.175:10983): avc:  denied  { write } for  pid=5609 comm="mount" name="/" dev="proc" ino=1 scontext=staff_u:staff_r:mock_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir

type=AVC msg=audit(1373203605.185:10984): avc:  denied  { write } for  pid=5610 comm="mount" name="/" dev="sysfs" ino=1 scontext=staff_u:staff_r:mock_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

type=AVC msg=audit(1373203605.193:10985): avc:  denied  { write } for  pid=5611 comm="mount" name="/" dev="tmpfs" ino=3360209 scontext=staff_u:staff_r:mock_t:s0 tcontext=staff_u:object_r:tmpfs_t:s0 tclass=dir

type=AVC msg=audit(1373203605.202:10986): avc:  denied  { write } for  pid=5612 comm="mount" name="/" dev="devpts" ino=1 scontext=staff_u:staff_r:mock_t:s0 tcontext=staff_u:object_r:devpts_t:s0 tclass=dir

type=AVC msg=audit(1373203605.202:10987): avc:  denied  { setattr } for  pid=5612 comm="mount" name="/" dev="devpts" ino=1 scontext=staff_u:staff_r:mock_t:s0 tcontext=staff_u:object_r:devpts_t:s0 tclass=dir

type=AVC msg=audit(1373203605.230:10988): avc:  denied  { mounton } for  pid=5615 comm="mount" path="/var/lib/mock/fedora-19-x86_64/root/proc/filesystems" dev="proc" ino=4026532021 scontext=staff_u:staff_r:mock_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

type=AVC msg=audit(1373203605.230:10989): avc:  denied  { mounton } for  pid=5615 comm="mount" path="/var/lib/mock/fedora-19-x86_64/root/proc/filesystems" dev="proc" ino=4026532021 scontext=staff_u:staff_r:mock_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file


All of them are related to mount, which should be autorized by the current policy :

allow mock_t mock_var_lib_t:dir mounton;
and 
kernel_mount_proc(mock_t)

Yet, this is blocked. 

I didn't tried further, since then mock fail. ( and so does Fedora-review )
Comment 1 Daniel Walsh 2013-07-08 15:10:48 EDT
What command did you actually run?
Comment 2 Michael Scherer 2013-07-10 04:24:31 EDT
I reproduced that with mock --init, and mock --clean.
Comment 3 Daniel Walsh 2013-07-10 19:37:36 EDT
The problem with mock is it requires root password to run which kind of ruins the separation we are trying to get with confined users.  Also some of the access it requires allows a confined user to break confinement.

mount_run(mock_t, staff_r)

Might fix a lot of the problems.
Comment 4 Michael Scherer 2013-07-11 09:01:46 EDT
Yeah, mock is not ideal to confine. 
I hope this would be better in a few versions due to userns and various things that permit to not run stuff as root. I will try to see if mount_run make it work .
Comment 5 Daniel Walsh 2013-07-16 13:48:15 EDT
Mock should be broken into two steps one, to setup the chroot environment and then one section to do the yum stuff.  If that was the case was the case we could break it into mock_priv_t and mock_t with mock_priv_t having more privs and dropping them when it does the actual install, which is what we are really worried about.
Comment 6 Michael Scherer 2013-07-17 12:49:52 EDT
I have a small patch that change the context of mock when it run a command in a chroot, but now, I wonder how and when this should be triggered.

Ie, should we attempt to do it unconditionally by default, should we hardcode the context to be mock_t with some overridable configuration ?

What do we do if it fail ( for example, no mock_t in the current policy ) ?
Comment 7 Daniel Walsh 2013-09-05 17:52:27 EDT
I would put something in the configuration that states that it should run as the user componant as mock_chroot_t and have this overridable in the confid and or on the command line.


mock_t to setup the chroot and mock_chroot_t to execute the actual rpms from the user.

If it fails to set the label in enforcing mode then the mock should fail. In permissive or disabled it should continue.
Comment 8 Fedora End Of Life 2015-01-09 13:44:09 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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 this bug is closed as described in the policy above.

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 9 Fedora End Of Life 2015-02-17 10:55:52 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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