Bug 1451379
Summary: | SELinux is preventing unix_chkpwd from using the 'dac_read_search' capabilities. | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Delete My Account <c.crispino8611> | |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 27 | CC: | alex.ploumistos, alick9188, amessina, awilliam, brunch875, carl, dominick.grift, dustymabe, dwalsh, jfrieben, joel, jsmith.fedora, kartochka378, kmansoft, kparal, lvrabec, mailinglists, makruiten, mgrepl, miabbott, mikhail.v.gavrilov, plautrba, pmoore, prd-fedora, rxguy, ssekidde, stefan+redhatbugs, vondruch | |
Target Milestone: | --- | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Unspecified | |||
Whiteboard: | AcceptedBlocker abrt_hash:6273a4068d4a412edf218f10c67e55f54ea074edf5acc8e0c9ce29d3e03e8f4b; | |||
Fixed In Version: | selinux-policy-3.13.1-260.4.fc26 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1485050 (view as bug list) | Environment: | ||
Last Closed: | 2017-10-04 14:32:32 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: | 1396704, 1485050, 1485055 |
Description
Delete My Account
2017-05-16 14:23:59 UTC
Description of problem: This is a fresh rawhide installation upgraded from a fresh f25 installation using the dnf upgrade plugin I was told in IRC the issue is due to a kernel change where the order of dac_read_search and dac_override changed to fix check dac_read_search Version-Release number of selected component: selinux-policy-3.13.1-255.fc27.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.12.0-0.rc3.git0.2.fc27.x86_64 type: libreport Description of problem: Happens on first boot of a current Rawhide Workstation install. Version-Release number of selected component: selinux-policy-3.13.1-258.fc27.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.12.0-0.rc5.git2.1.fc27.x86_64 type: libreport This is clearly not fixed. Also clearly similar to https://bugzilla.redhat.com/show_bug.cgi?id=1451377 , but not the same (two different things that deal with accounts, hitting the same denial). Proposing as an F27 Final blocker: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." Description of problem: Locked my desktop, then logged back in. Saw that this SELinux alert happened during the login process. Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.13.0-0.rc0.git3.1.fc27.x86_64 type: libreport Description of problem: Just load Rawhide from USB stick Version-Release number of selected component: selinux-policy-3.13.1-263.fc27.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.13.0-0.rc0.git6.1.fc27.x86_64 type: libreport Description of problem: Occured when launch google-chrome Version-Release number of selected component: selinux-policy-3.13.1-263.fc27.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.13.0-0.rc0.git6.1.fc27.x86_64 type: libreport This is also being seen on Fedora Rawhide Atomic Host. # rpm-ostree status State: idle Deployments: ● rawhide:fedora/rawhide/x86_64/atomic-host Version: Rawhide.20170724.n.0 (2017-07-24 11:01:23) Commit: 508fedeefc8c6a00516070a7edacc1c05edd34a3471c1e6ebc3f8bb4f2640f88 # rpm -q selinux-policy selinux-policy-3.13.1-265.fc27.noarch # journalctl -b | grep denied Jul 25 16:07:36 micah-f26ah-vm0725a.localdomain audit[1086]: AVC avc: denied { dac_read_search } for pid=1086 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=capability permissive=0 Jul 25 16:07:36 micah-f26ah-vm0725a.localdomain audit[1088]: AVC avc: denied { dac_read_search } for pid=1088 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability permissive=0 Same here on F26 with kernel 4.12 (just updated from 4.11), and not just for unix_chkpwd $ rpm -q selinux-policy selinux-policy-3.13.1-260.3.fc26.noarch $ $ rpm -q kernel-core kernel-core-4.11.11-300.fc26.x86_64 kernel-core-4.12.4-300.fc26.x86_64 Jul 29 16:43:02 fiona audit[782]: AVC avc: denied { dac_read_search } for pid=782 comm="systemd-logind" capability=2 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=capability permissive=0 Jul 29 16:43:02 fiona audit[1323]: AVC avc: denied { dac_read_search } for pid=1323 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability permissive=0 Jul 29 16:43:02 fiona audit[794]: AVC avc: denied { dac_read_search } for pid=794 comm="accounts-daemon" capability=2 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=0 Every boot I have this annoying popup, F26 + updates-testing, dac_read_search with processes (usermod, sm_notify, unix_chkpwd, accounts_daemon, systemd-tempfile ) many times. I ignore them, as all seems work ok in GNOME. This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. Encountering the same on Fedora 26. Can confirm a similar AVC denied happens to other processes as mentioned by kartochka22. Snippet of: $ journalctl -b | grep denied .. Aug 15 10:18:05 aether audit[3652]: AVC avc: denied { dac_read_search } for pid=3652 comm="systemd-tmpfile" capability=2 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:system_r:systemd_tmpfiles_t:s0 tclass=capability permissive=0 Aug 15 10:18:10 aether audit[3656]: AVC avc: denied { read } for pid=3656 comm="setroubleshootd" name="Packages" dev="sda2" ino=916241 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 Aug 15 10:18:10 aether org.fedoraproject.Setroubleshootd[605]: error: cannot open Packages index using db5 - Permission denied (13) Aug 15 10:18:10 aether audit[3660]: AVC avc: denied { read } for pid=3660 comm="rpm" name="Packages" dev="sda2" ino=916241 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 Aug 15 10:18:10 aether org.fedoraproject.Setroubleshootd[605]: error: cannot open Packages index using db5 - Permission denied (13) .. $ rpm -q selinux-policy kernel-core selinux-policy-3.13.1-260.3.fc26.noarch kernel-core-4.11.11-200.fc25.x86_64 kernel-core-4.11.11-300.fc26.x86_64 kernel-core-4.12.5-300.fc26.x86_64 Let me know if I should try to get the error again with full auditing mode enabled. === SELinux is preventing unix_chkpwd from using the dac_read_search capability. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that unix_chkpwd should have the dac_read_search 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: # ausearch -c 'unix_chkpwd' --raw | audit2allow -M my-unixchkpwd # semodule -X 300 -i my-unixchkpwd.pp Additional Information: Source Context system_u:system_r:chkpwd_t:s0-s0:c0.c1023 Target Context system_u:system_r:chkpwd_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source unix_chkpwd Source Path unix_chkpwd Port <Unknown> Host aether Source RPM Packages Target RPM Packages Policy RPM <Unknown> Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name aether Platform Linux aether 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 x86_64 Alert Count 6 First Seen 2017-08-15 13:16:01 CEST Last Seen 2017-08-15 13:39:11 CEST Local ID e2a5b768-502f-47cd-9c88-f7abeb6779b5 Raw Audit Messages type=AVC msg=audit(1502797151.127:1151): avc: denied { dac_read_search } for pid=7085 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=capability permissive=0 Hash: unix_chkpwd,chkpwd_t,chkpwd_t,capability,dac_read_search This appears to be fixed in Rawhide Atomic Host with 'selinux-policy-3.13.1-270.fc27.noarch' # rpm-ostree status State: idle Deployments: ● rawhide:fedora/rawhide/x86_64/atomic-host Version: Rawhide.20170815.n.1 (2017-08-15 20:34:47) Commit: a5b8ef53e3e93ed057c65e0d2b0ddea7f392862e77b930595dca9c7811abbd78 # rpm -q selinux-policy selinux-policy-3.13.1-270.fc27.noarch # grep 'avc: denied' /var/log/audit/audit.log # Discussed during blocker review [1]: AcceptedBlocker (Final) - clear violations of Final criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-08-21/ Also seen on Fedora 25 FYI. This is also a problem on RHEL/CentOS 7.4 time->Thu Sep 14 14:35:01 2017 type=PROCTITLE msg=audit(1505363701.286:13237): proctitle=2F7573722F7362696E2F756E69785F63686B70776400726F6F740063686B657870697279 type=SYSCALL msg=audit(1505363701.286:13237): arch=c000003e syscall=2 success=yes exit=3 a0=7f5b6822e453 a1=80000 a2=1b6 a3=24 items=0 ppid=25143 pid=25146 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1505363701.286:13237): avc: denied { dac_read_search } for pid=25146 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=capability permissive=0 (In reply to Sam McLeod from comment #15) > This is also a problem on RHEL/CentOS 7.4 > > > time->Thu Sep 14 14:35:01 2017 > type=PROCTITLE msg=audit(1505363701.286:13237): > proctitle=2F7573722F7362696E2F756E69785F63686B70776400726F6F740063686B6578706 > 97279 > type=SYSCALL msg=audit(1505363701.286:13237): arch=c000003e syscall=2 > success=yes exit=3 a0=7f5b6822e453 a1=80000 a2=1b6 a3=24 items=0 ppid=25143 > pid=25146 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" > exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 > key=(null) > type=AVC msg=audit(1505363701.286:13237): avc: denied { dac_read_search } > for pid=25146 comm="unix_chkpwd" capability=2 > scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=capability > permissive=0 I can reliably reproduce this on RHEL/CentOS 7.4 using a libreswan IPSec XAuth authenticated configuration using PAM auth (e.g. https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv1_XAUTH_with_PSK ), and the connection fails to establish with selinux enforcing: conn xauth-psk .... xauthby=pam type=CRYPTO_IKE_SA msg=audit(1505716250.380:202): pid=1915 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ipsec_t:s0 msg='op=start direction=responder conn-name="xauth-psk" connstate=7 ike-version=1 auth=PRESHARED_KEY cipher=aes ksize=256 integ=sha256 prf=sha256 pfs=MODP2048 laddr=<local> exe="/usr/libexec/ipsec/pluto" hostname=? addr=<remote> terminal=? res=success' type=AVC msg=audit(1505716250.478:203): avc: denied { dac_read_search } for pid=2428 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability type=SYSCALL msg=audit(1505716250.478:203): arch=c000003e syscall=2 success=no exit=-13 a0=7fa919172453 a1=80000 a2=1b6 a3=24 items=0 ppid=1915 pid=2428 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0 key=(null) This seems to be related to file permissions on /etc/shadow, as per comments in RHBZ #1459910. If I change the permissions on /etc/shadow to 0400 it works fine and the IPSec connection is successful with selinux enforcing: [root@hirudinea ~]# ls -al /etc/shadow ----------. 1 root root 968 Aug 7 06:32 /etc/shadow [root@hirudinea ~]# chmod 400 /etc/shadow [root@hirudinea ~]# ls -al /etc/shadow -r--------. 1 root root 968 Aug 7 06:32 /etc/shadow [root@hirudinea ~]# getenforce Enforcing type=CRYPTO_IKE_SA msg=audit(1505717388.773:294): pid=1915 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ipsec_t:s0 msg='op=start direction=responder conn-name="xauth-psk" connstate=8 ike-version=1 auth=PRESHARED_KEY cipher=aes ksize=256 integ=sha256 prf=sha256 pfs=MODP2048 laddr=<local> exe="/usr/libexec/ipsec/pluto" hostname=? addr=<remote> terminal=? res=success' type=USER_AUTH msg=audit(1505717388.904:295): pid=1915 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ipsec_t:s0 msg='op=PAM:authentication grantors=pam_unix acct="pam-username" exe="/usr/libexec/ipsec/pluto" hostname=<remote> addr=<remote> terminal=? res=success' Just FYI, /etc/shadow has been with the mod 0000 for long in Fedora (since F12). See https://fedoraproject.org/wiki/Features/LowerProcessCapabilities Seems to me selinux should not deny these processes' capabilities. Alick, this was a change in the kernel, which caused this issue. chpwd_t has DAC_OVERRIDE, which has always allowed it to read the file. But the kernel has two checks Old kernel If DAC_OVERRIDE or DAC_READ_SEARCH Read a file with 0000 mode. New Kernel If DAC_READ_SEARCH or DAC_OVERRIDE Read a file with 0000 mode. Since the chkpwd_t had DAC_OVERRIDE in the older kernels, it never checked DAC_READ_SEARCH and therefore DAC_READ_SEARCH was never added to policy. Now it is checking DAC_READ_SEARCH first so we see the AVC being generated even though the final access was allowed. (In reply to Daniel Walsh from comment #18) > Alick, this was a change in the kernel, which caused this issue. chpwd_t > has DAC_OVERRIDE, which has always allowed it to read the file. But the > kernel has two checks > > Old kernel > > If DAC_OVERRIDE or DAC_READ_SEARCH > Read a file with 0000 mode. > > New Kernel > > > If DAC_READ_SEARCH or DAC_OVERRIDE > Read a file with 0000 mode. > > Since the chkpwd_t had DAC_OVERRIDE in the older kernels, it never checked > DAC_READ_SEARCH and therefore DAC_READ_SEARCH was never added to policy. > Now it is checking DAC_READ_SEARCH first so we see the AVC being generated > even though the final access was allowed. Hi Daniel, Thanks for the nice explanation. So the AVC's are actually false alarms triggered by kernel changes. But still, the AVC's and abrt popups are kinda annoying. And it does not hurt to grant DAC_READ_SEARCH capability, does it? This seems to be fixed in Fedora. Is it still a problem in RHEL? I actually wrote a blog on this. https://danwalsh.livejournal.com/77140.html Anyways I don't think this change to the kernel has made its way to RHEL yet. DAC_READ_SEARCH is less dangerous then DAC_OVERRIDE, but it basically allows a domain to read any file on the system, from a DAC point of view. SELinux would still prevent you from a type enforcement point of view. Per comment 12, this sounds fixed, and the selinux-build is already stable, so closing. |