Bug 986122

Summary: SELinux is preventing /usr/sbin/useradd from using the 'sys_chroot' capabilities.
Product: [Fedora] Fedora Reporter: Jon Disnard <jdisnard>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA 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: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:77f238bde52584a98aca4c372b3b9f72b959af3b95d0847de8f8a7fca6904989
Fixed In Version: selinux-policy-3.12.1-66.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-26 23:05:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jon Disnard 2013-07-19 02:30:40 UTC
Description of problem:

So I was manually crafting a fedora-arm live image for the beagle bone black.
Part of my process involves creating a "liveuser" with useradd(8) and groupadd(8).

What happens is an ext4 rootfs is loop-mounted on /mnt, and the rootfs manipulated.

In this instance the useradd(8) cmd was used like so:

# useradd  -u 2333 -g 2333 -G 10 --root /mnt liveuser


The work around was to manually chroot like so:

# chroot /mnt useradd  -u 2333 -g 2333 -G 10 liveuser


SELinux is preventing /usr/sbin/useradd from using the 'sys_chroot' capabilities.


Here is the cmdline that triggered the AVC:
# useradd  -u 2333 -g 2333 -G 10 --root /mnt liveuser

Useradd(8) has --root (chroot) capability, which wants sys_chroot ability.
Also groupadd(8) might be impacted the same way.

Ran into this one when adding a "liveuser" to a rootfs mounted on /mnt.
Want to leave selinux enabled on machines used to generate Fedora images or spins.


*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that useradd should have the sys_chroot capability 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:unconfined_r:useradd_t:s0-s0:c0.c1023
Target Objects                 [ capability ]
Source                        useradd
Source Path                   /usr/sbin/useradd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           shadow-utils-4.1.5.1-5.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-63.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.9.9-302.fc19.x86_64 #1 SMP Sat
                              Jul 6 13:41:07 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-07-15 16:02:35 CDT
Last Seen                     2013-07-15 16:02:35 CDT
Local ID                      66d08c43-efca-41fd-bbca-21103ece3487

Raw Audit Messages
type=AVC msg=audit(1373922155.580:389): avc:  denied  { sys_chroot } for  pid=16170 comm="useradd" capability=18  scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tclass=capability


type=SYSCALL msg=audit(1373922155.580:389): arch=x86_64 syscall=chroot success=yes exit=0 a0=7fff822d370a a1=0 a2=0 a3=7f0fd804a2e0 items=0 ppid=2970 pid=16170 auid=80870 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=1 tty=pts8 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null)

Hash: useradd,useradd_t,useradd_t,capability,sys_chroot

Additional info:
reporter:       libreport-2.1.5
hashmarkername: setroubleshoot
kernel:         3.9.9-302.fc19.x86_64
type:           libreport

Comment 1 Miroslav Grepl 2013-07-19 07:45:04 UTC
commit f6367a3649b2e2e957df2cba67f4b5ea2ec297ce
Author: Miroslav Grepl <mgrepl>
Date:   Fri Jul 19 09:44:54 2013 +0200

    Allow sys_chroot for useradd_t

Comment 2 Fedora Update System 2013-07-24 14:11:13 UTC
selinux-policy-3.12.1-66.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-66.fc19

Comment 3 Fedora Update System 2013-07-25 00:34:43 UTC
Package selinux-policy-3.12.1-66.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-66.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13543/selinux-policy-3.12.1-66.fc19
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2013-07-26 23:05:37 UTC
selinux-policy-3.12.1-66.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.