Bug 1451379 - SELinux is preventing unix_chkpwd from using the 'dac_read_search' capabilities.
Summary: SELinux is preventing unix_chkpwd from using the 'dac_read_search' capabilities.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker abrt_hash:6273a4068d4...
Depends On:
Blocks: F27FinalBlocker 1485050 1485055
TreeView+ depends on / blocked
 
Reported: 2017-05-16 14:23 UTC by Delete My Account
Modified: 2018-01-07 10:35 UTC (History)
28 users (show)

Fixed In Version: selinux-policy-3.13.1-260.4.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1485050 (view as bug list)
Environment:
Last Closed: 2017-10-04 14:32:32 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1451377 0 unspecified CLOSED SELinux is preventing accounts-daemon from using the 'dac_read_search' capabilities. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1451381 0 unspecified CLOSED SELinux is preventing sm-notify from using the 'dac_read_search' capabilities. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1451385 0 unspecified CLOSED SELinux is preventing systemd-tmpfile from using the 'dac_read_search' capabilities. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1459081 0 unspecified CLOSED SELinux is preventing abrt-server from using the 'dac_read_search' capabilities. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1532001 0 unspecified CLOSED SELinux is preventing /usr/sbin/unix_chkpwd from using the dac_read_search capability 2021-02-22 00:41:40 UTC


Description Delete My Account 2017-05-16 14:23:59 UTC
Description of problem:
SELinux is preventing unix_chkpwd from using the 'dac_read_search' capabilities.

*****  Plugin dac_override (91.4 confidence) suggests   **********************

If si vuole aiutare ad identificare se al dominio serva questo accesso o se si possiede un file con i permessi sbagliati sul sistema
Then attivare l'auditing completo per ottenere le informazioni del percorso del file incriminato e generare nuovamente l'errore.
Do

Attivare il controllo completo auditing
# auditctl -w /etc/shadow -p w
Provare a ricreare AVC. Eseguire quindi
# ausearch -m avc -ts recent
Qualora si noti il record PATH, controllare la proprietà/i permessi sul file e correggerli,
altrimenti registrare un bugzilla.

*****  Plugin catchall (9.59 confidence) suggests   **************************

If si pensa che unix_chkpwd dovrebbe avere funzionalità dac_read_search in modo predefinito.
Then si dovrebbe riportare il problema come bug.
E' possibile generare un modulo di politica locale per consentire questo accesso.
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
Target Context                system_u:system_r:chkpwd_t:s0
Target Objects                Unknown [ capability ]
Source                        unix_chkpwd
Source Path                   unix_chkpwd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-253.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.12.0-0.rc0.git9.1.fc27.x86_64 #1
                              SMP Sat May 13 13:39:12 UTC 2017 x86_64 x86_64
Alert Count                   6
First Seen                    2017-05-07 08:23:53 CEST
Last Seen                     2017-05-16 16:20:41 CEST
Local ID                      5f2519a9-9c2b-45de-b7c3-1b486e94b63a

Raw Audit Messages
type=AVC msg=audit(1494944441.355:295): avc:  denied  { dac_read_search } for  pid=1069 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


Hash: unix_chkpwd,chkpwd_t,chkpwd_t,capability,dac_read_search

Version-Release number of selected component:
selinux-policy-3.13.1-253.fc27.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.9.1
hashmarkername: setroubleshoot
kernel:         4.12.0-0.rc0.git9.1.fc27.x86_64
type:           libreport

Comment 1 Bruno Javier Blasco Smaranda 2017-06-06 08:58:56 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

Comment 2 Adam Williamson 2017-06-19 23:48:13 UTC
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

Comment 3 Adam Williamson 2017-06-19 23:49:34 UTC
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."

Comment 4 Jared Smith 2017-07-14 22:46:57 UTC
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

Comment 5 Mikhail 2017-07-15 16:36:23 UTC
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

Comment 6 Mikhail 2017-07-15 17:06:11 UTC
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

Comment 7 Micah Abbott 2017-07-25 16:23:36 UTC
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

Comment 8 Kostya Vasilyev 2017-07-29 13:47:28 UTC
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

Comment 9 kartochka378 2017-08-14 09:37:24 UTC
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.

Comment 10 Jan Kurik 2017-08-15 08:55:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 11 Stefan Joosten 2017-08-15 11:53:56 UTC
Encountering the same on Fedora 26.
Can confirm a similar AVC denied happens to other processes as mentioned by kartochka22@yandex.ru.

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

Comment 12 Micah Abbott 2017-08-16 19:06:41 UTC
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 
#

Comment 13 Kamil Páral 2017-08-21 17:29:06 UTC
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/

Comment 14 Alick Zhao 2017-08-27 01:00:28 UTC
Also seen on Fedora 25 FYI.

Comment 15 Sam McLeod 2017-09-14 04:36:14 UTC
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

Comment 16 Joel Michael 2017-09-18 07:08:23 UTC
(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'

Comment 17 Alick Zhao 2017-09-18 15:57:51 UTC
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.

Comment 18 Daniel Walsh 2017-09-22 16:04:26 UTC
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.

Comment 19 Alick Zhao 2017-09-24 15:12:21 UTC
(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?

Comment 20 Daniel Walsh 2017-09-25 14:11:04 UTC
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.

Comment 21 Kamil Páral 2017-10-04 14:32:32 UTC
Per comment 12, this sounds fixed, and the selinux-build is already stable, so closing.


Note You need to log in before you can comment on or make changes to this bug.