Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1024075
Summary: | SELinux prevents virt-* tools from running when sssd is being used | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeff Bastian <jbastian> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | dominick.grift, dwalsh, jbastian, lvrabec, mgrepl, mmarzantowicz, rjones |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:338e5cceb5235af1128299ac4f24a580b83bcaa44a66b7477f8fa1ff11e123c8 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-12-06 20:24:04 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: | |||
Bug Depends On: | |||
Bug Blocks: | 910269 |
Description
Jeff Bastian
2013-10-28 18:21:43 UTC
On my machine: $ getenforce Enforcing and virt-builder works. However I don't use sssd, I don't think (not even sure what it is). I'm a bit confused why virt-builder (or bash?) needs access to the password file. By the way, the raw audit log indicates the problem is with qemu-kvm, not bash. Does the following command also have the same SELinux AVC: libguestfs-test-tool sssd is an authentication daemon that can talk to LDAP, Kerberos, Active Directory, etc. and it provides nice features like credential caching so you can login to your system with your LDAP/Kerberos credentials even when the laptop is not connected to the corporate network. So anything auth related will go through sssd on a system that uses it, e.g., login, screen savers and lockers, sudo, polkit, etc. Indeed, libguestfs-test-tool gets the same AVC, although the command appears to finish running successfully: ~]$ date Mon Oct 28 15:54:20 CDT 2013 ~]$ libguestfs-test-tool ... libguestfs: command: run: rm libguestfs: command: run: \ -rf /tmp/libguestfsxfky0R ===== TEST FINISHED OK ===== ~]$ sudo ausearch -ts recent -m avc ---- time->Mon Oct 28 15:54:30 2013 type=SYSCALL msg=audit(1382993670.394:4813): arch=c000003e syscall=2 success=no exit=-13 a0=1d64110 a1=80000 a2=7ffffed9e544 a3=7ffffed9e2d0 items=0 ppid=1 pid=31535 auid=12257 uid=12257 gid=12257 euid=12257 suid=12257 fsuid=12257 egid=12257 sgid=12257 fsgid=12257 ses=2 tty=(none) comm="qemu-kvm" exe="/usr/bin/bash" subj=unconfined_u:system_r:svirt_t:s0:c354,c928 key=(null) type=AVC msg=audit(1382993670.394:4813): avc: denied { read } for pid=31535 comm="qemu-kvm" name="passwd" dev="dm-2" ino=6031555 scontext=unconfined_u:system_r:svirt_t:s0:c354,c928 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file We can probably add a dontaudit rule, since we don't want svirt_t to be able to dump the password database. I ran in Permissive mode to see if anything else might be blocked and it appears it's just the usual suspects for reading a file: getattr, open and read. ~]$ sudo setenforce 0 ~]$ libguestfs-test-tool ... ~]$ sudo ausearch -ts recent -m avc ---- time->Mon Oct 28 16:08:52 2013 type=SYSCALL msg=audit(1382994532.937:4960): arch=c000003e syscall=5 success=yes exit=0 a0=3 a1=7fff3e819be0 a2=7fff3e819be0 a3=7fff3e819990 items=0 ppid=1 pid=566 auid=12257 uid=12257 gid=12257 euid=12257 suid=12257 fsuid=12257 egid=12257 sgid=12257 fsgid=12257 ses=2 tty=(none) comm="qemu-kvm" exe="/usr/bin/bash" subj=unconfined_u:system_r:svirt_t:s0:c505,c631 key=(null) type=AVC msg=audit(1382994532.937:4960): avc: denied { getattr } for pid=566 comm="qemu-kvm" path="/var/lib/sss/mc/passwd" dev="dm-2" ino=6031555 scontext=unconfined_u:system_r:svirt_t:s0:c505,c631 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file ---- time->Mon Oct 28 16:08:52 2013 type=SYSCALL msg=audit(1382994532.937:4959): arch=c000003e syscall=2 success=yes exit=3 a0=10a3110 a1=80000 a2=7fff3e819bd4 a3=7fff3e819960 items=0 ppid=1 pid=566 auid=12257 uid=12257 gid=12257 euid=12257 suid=12257 fsuid=12257 egid=12257 sgid=12257 fsgid=12257 ses=2 tty=(none) comm="qemu-kvm" exe="/usr/bin/bash" subj=unconfined_u:system_r:svirt_t:s0:c505,c631 key=(null) type=AVC msg=audit(1382994532.937:4959): avc: denied { open } for pid=566 comm="qemu-kvm" path="/var/lib/sss/mc/passwd" dev="dm-2" ino=6031555 scontext=unconfined_u:system_r:svirt_t:s0:c505,c631 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file type=AVC msg=audit(1382994532.937:4959): avc: denied { read } for pid=566 comm="qemu-kvm" name="passwd" dev="dm-2" ino=6031555 scontext=unconfined_u:system_r:svirt_t:s0:c505,c631 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file And audit2allow confirms it: ~]$ cd /tmp tmp]$ sudo audit2allow -b -M libguestfs tmp]$ cat libguestfs.te module libguestfs 1.0; require { type svirt_t; type sssd_public_t; class file { read getattr open }; } #============= svirt_t ============== allow svirt_t sssd_public_t:file { read getattr open }; Or, using the reference policy: tmp]$ sudo audit2allow -b -R -M libguestfs tmp]$ cat libguestfs.te policy_module(libguestfs, 1.0) require { type svirt_t; } #============= svirt_t ============== auth_use_nsswitch(svirt_t) We currently block write, so I guess we should block read also. 481529a433ae112e044cd8db93b4d2b240e62366 fixes this in git. bc266def17512628a346c9dc12c125456c1deeec also needed. I'll just say that libguestfs calls getgrnam ("qemu") in order to find out what group to chown a file to: https://github.com/libguestfs/libguestfs/blob/276cde033c454e084e38c36af693c3fcad86281f/src/launch-libvirt.c#L369 I don't understand the AVC at all however: comm="qemu-kvm" exe="/usr/bin/bash" subj=unconfined_u:system_r:svirt_t[...] The process is qemu-kvm running in svirt_t. That part makes sense. So why is exe bash? (In reply to Richard W.M. Jones from comment #1) > I'm a bit confused why virt-builder (or bash?) needs access > to the password file. I used SystemTap to print a backtrace on every audit event: https://sourceware.org/systemtap/examples/process/auditbt.stp And this is what I see when I run libguestfs-test-tool (in another shell): $ sudo stap auditbt.stp -d /usr/lib64/libc-2.18.so \ -d /usr/lib64/libaudit.so.1.0.0 -d /usr/lib64/libpam.so.0.83.1 \ -d /usr/lib64/libnss_sss.so.2 -d /usr/lib64/security/pam_loginuid.so \ -d /usr/bin/bash -d /usr/bin/libguestfs-test-tool qemu-kvm[18111] audit(1383248797.470:1271): avc: denied { read } for pid=18111 comm="qemu-kvm" name="passwd" dev="dm-2" ino=6031690 scontext=unconfined_u:system_r:svirt_t:s0:c111,c455 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file 0x7f2790506640 : __open_nocancel+0x7/0x57 [/usr/lib64/libc-2.18.so] 0x7f279000f3f2 : sss_open_cloexec+0x32/0x60 [/usr/lib64/libnss_sss.so.2] 0x7f279000f01c : sss_nss_mc_get_ctx+0xdc/0x2a0 [/usr/lib64/libnss_sss.so.2] 0x7f279000f859 : sss_nss_mc_getpwuid+0x49/0x160 [/usr/lib64/libnss_sss.so.2] 0x7f279000d226 : _nss_sss_getpwuid_r+0x66/0x180 [/usr/lib64/libnss_sss.so.2] 0x7f27904dbe0c : getpwuid_r@@GLIBC_2.2.5+0xdc/0x280 [/usr/lib64/libc-2.18.so] 0x7f27904db6a6 : getpwuid+0x76/0x13e [/usr/lib64/libc-2.18.so] 0x41db71 : get_current_user_info+0x21/0x160 [/usr/bin/bash] 0x43a5c5 : initialize_shell_variables+0xb55/0xbb0 [/usr/bin/bash] 0x41dd37 : shell_initialize+0x87/0x1a0 [/usr/bin/bash] 0x41c433 : main+0x7f3/0x16d4 [/usr/bin/bash] 0x7f2790441d65 : __libc_start_main+0xf5/0x1c0 [/usr/lib64/libc-2.18.so] 0x41d33d : _start+0x29/0x2c [/usr/bin/bash] qemu-kvm[18111] audit(1383248797.470:1271): arch=c000003e syscall=2 success=no exit=-13 a0=cc7110 a1=80000 a2=7fffd98f86b4 a3=7fffd98f8440 items=0 ppid=1 pid=18111 auid=12257 uid=12257 gid=12257 euid=12257 suid=12257 fsuid=12257 egid=12257 sgid=12257 fsgid=12257 ses=1 tty=(none) comm="qemu-kvm" exe="/usr/bin/bash" subj=unconfined_u:system_r:svirt_t:s0:c111,c455 key=(null) 0x7f2790506640 : __open_nocancel+0x7/0x57 [/usr/lib64/libc-2.18.so] 0x7f279000f3f2 : sss_open_cloexec+0x32/0x60 [/usr/lib64/libnss_sss.so.2] 0x7f279000f01c : sss_nss_mc_get_ctx+0xdc/0x2a0 [/usr/lib64/libnss_sss.so.2] 0x7f279000f859 : sss_nss_mc_getpwuid+0x49/0x160 [/usr/lib64/libnss_sss.so.2] 0x7f279000d226 : _nss_sss_getpwuid_r+0x66/0x180 [/usr/lib64/libnss_sss.so.2] 0x7f27904dbe0c : getpwuid_r@@GLIBC_2.2.5+0xdc/0x280 [/usr/lib64/libc-2.18.so] 0x7f27904db6a6 : getpwuid+0x76/0x13e [/usr/lib64/libc-2.18.so] 0x41db71 : get_current_user_info+0x21/0x160 [/usr/bin/bash] 0x43a5c5 : initialize_shell_variables+0xb55/0xbb0 [/usr/bin/bash] 0x41dd37 : shell_initialize+0x87/0x1a0 [/usr/bin/bash] 0x41c433 : main+0x7f3/0x16d4 [/usr/bin/bash] 0x7f2790441d65 : __libc_start_main+0xf5/0x1c0 [/usr/lib64/libc-2.18.so] 0x41d33d : _start+0x29/0x2c [/usr/bin/bash] qemu-kvm[18111] audit(1383248797.470:1271): 0x7f2790506640 : __open_nocancel+0x7/0x57 [/usr/lib64/libc-2.18.so] 0x7f279000f3f2 : sss_open_cloexec+0x32/0x60 [/usr/lib64/libnss_sss.so.2] 0x7f279000f01c : sss_nss_mc_get_ctx+0xdc/0x2a0 [/usr/lib64/libnss_sss.so.2] 0x7f279000f859 : sss_nss_mc_getpwuid+0x49/0x160 [/usr/lib64/libnss_sss.so.2] 0x7f279000d226 : _nss_sss_getpwuid_r+0x66/0x180 [/usr/lib64/libnss_sss.so.2] 0x7f27904dbe0c : getpwuid_r@@GLIBC_2.2.5+0xdc/0x280 [/usr/lib64/libc-2.18.so] 0x7f27904db6a6 : getpwuid+0x76/0x13e [/usr/lib64/libc-2.18.so] 0x41db71 : get_current_user_info+0x21/0x160 [/usr/bin/bash] 0x43a5c5 : initialize_shell_variables+0xb55/0xbb0 [/usr/bin/bash] 0x41dd37 : shell_initialize+0x87/0x1a0 [/usr/bin/bash] 0x41c433 : main+0x7f3/0x16d4 [/usr/bin/bash] 0x7f2790441d65 : __libc_start_main+0xf5/0x1c0 [/usr/lib64/libc-2.18.so] 0x41d33d : _start+0x29/0x2c [/usr/bin/bash] This bug also occurs when running virt-ls command but it doesn't show up when doing virt-cat. I confirm that I use sssd (as part of FreeIPA client installation) on that machine. Below is more info about this problem: Additional Information: Source Context unconfined_u:system_r:svirt_t:s0:c542,c910 Target Context system_u:object_r:sssd_public_t:s0 Target Objects /var/lib/sss/mc/passwd [ file ] Source qemu-kvm Source Path /usr/bin/bash Port <Nieznane> Host hive.local Source RPM Packages bash-4.2.45-4.fc20.x86_64 Target RPM Packages sssd-common-1.11.2-1.fc20.x86_64 Policy RPM selinux-policy-3.12.1-90.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hive.local Platform Linux hive.local 3.11.7-300.fc20.x86_64 #1 SMP Mon Nov 4 15:07:39 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-11-12 11:38:48 CET Last Seen 2013-11-12 11:38:48 CET Local ID 330270f8-c017-411c-882e-46bcbcc8819d Raw Audit Messages type=AVC msg=audit(1384252728.489:722): avc: denied { read } for pid=518 comm="qemu-kvm" name="passwd" dev="dm-4" ino=1180023 scontext=unconfined_u:system_r:svirt_t:s0:c542,c910 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file type=SYSCALL msg=audit(1384252728.489:722): arch=x86_64 syscall=open success=no exit=EACCES a0=b62160 a1=80000 a2=7fff36947df4 a3=7fff36947b80 items=0 ppid=1 pid=518 auid=1593800001 uid=1593800001 gid=1593800001 euid=1593800001 suid=1593800001 fsuid=1593800001 egid=1593800001 sgid=1593800001 fsgid=1593800001 ses=15 tty=(none) comm=qemu-kvm exe=/usr/bin/bash subj=unconfined_u:system_r:svirt_t:s0:c542,c910 key=(null) Hash: qemu-kvm,svirt_t,sssd_public_t,file,read It also occurs with virt-cat. I apologize for invalid info on previous post. (In reply to Daniel Walsh from comment #5) > We currently block write, so I guess we should block read also. > > 481529a433ae112e044cd8db93b4d2b240e62366 fixes this in git. Which git repo does this refer to? I can't understand the selinux-policy spec file at all. Is there no upstream source? (In reply to Richard W.M. Jones from comment #11) > Which git repo does this refer to? I can't understand the > selinux-policy spec file at all. Is there no upstream source? https://git.fedorahosted.org/cgit/selinux-policy.git/commit/?id=481529a433ae112e044cd8db93b4d2b240e62366 (In reply to Mateusz Marzantowicz from comment #10) > It also occurs with virt-cat. I apologize for invalid info on previous post. Based on my reading of the source in Fedora & Jeff's comment 12, I believe this issue should be fixed now. However you will need to ensure you have selinux-policy >= 3.12.1-100.fc20 If this issue happens and you have selinux-policy greater than or equal to that version installed, then let us know on this bug report. $ rpm -qa selinux-policy* selinux-policy-targeted-3.12.1-100.fc20.noarch selinux-policy-3.12.1-100.fc20.noarch Files system was relabeled. The bus still exists (virt-ls and virt-cat). Additional Information: Source Context unconfined_u:system_r:svirt_t:s0:c234,c620 Target Context system_u:object_r:sssd_public_t:s0 Target Objects /var/lib/sss/mc/passwd [ file ] Source qemu-kvm Source Path /usr/bin/bash Port <Nieznane> Host hive.local Source RPM Packages bash-4.2.45-4.fc20.x86_64 Target RPM Packages sssd-common-1.11.2-1.fc20.x86_64 Policy RPM selinux-policy-3.12.1-100.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hive.local Platform Linux hive.local 3.11.7-300.fc20.x86_64 #1 SMP Mon Nov 4 15:07:39 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-11-12 17:21:11 CET Last Seen 2013-11-12 17:21:11 CET Local ID 6c5fc00c-d36a-4056-a497-cd94533a1e72 Raw Audit Messages type=AVC msg=audit(1384273271.853:132): avc: denied { read } for pid=2888 comm="qemu-kvm" name="passwd" dev="dm-4" ino=1180023 scontext=unconfined_u:system_r:svirt_t:s0:c234,c620 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file type=SYSCALL msg=audit(1384273271.853:132): arch=x86_64 syscall=open success=no exit=EACCES a0=15f6160 a1=80000 a2=7fff83122904 a3=7fff83122690 items=0 ppid=1 pid=2888 auid=1593800001 uid=1593800001 gid=1593800001 euid=1593800001 suid=1593800001 fsuid=1593800001 egid=1593800001 sgid=1593800001 fsgid=1593800001 ses=1 tty=(none) comm=qemu-kvm exe=/usr/bin/bash subj=unconfined_u:system_r:svirt_t:s0:c234,c620 key=(null) Hash: qemu-kvm,svirt_t,sssd_public_t,file,read BTW, I can run virt-* commands successfully. selinux alert pops out but I get requested result from that commands (it's just in reference to bug's title). (In reply to Mateusz Marzantowicz from comment #15) > BTW, I can run virt-* commands successfully. selinux alert pops out but I > get requested result from that commands (it's just in reference to bug's > title). TBH I'm not sure if this is correct behaviour or not. I suspect not because AIUI the purpose of the dontaudit rule is that SELinux ignores (but fails) the access. Dan/Jeff care to comment on this? df08dde51666efaf40adc05bf540e2369540e297 adds a dontaudit for this in git. |