Bug 906679 - Failed passwd rootok action isn't logged into audit.log
Failed passwd rootok action isn't logged into audit.log
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
Unspecified Linux
unspecified Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: 965723 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-02-01 03:24 EST by Ludek Finstrle
Modified: 2013-07-24 20:48 EDT (History)
5 users (show)

See Also:
Fixed In Version: pam-1.1.6-4.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-13 23:31:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
selinux policy with passwd rootok commented out (1.22 KB, application/octet-stream)
2013-02-01 03:24 EST, Ludek Finstrle
no flags Details

  None (edit)
Description Ludek Finstrle 2013-02-01 03:24:20 EST
Created attachment 691423 [details]
selinux policy with passwd rootok commented out

Description of problem:
I needed to use /usr/bin/su in cups backend.
I enabled debug using semodule -BD. I went througth:
grep pool /var/log/audit/audit.log | audit2allow -M test
semodule -i test

I reached the point where no relevant AVC denied is in audit.log. However it didn't work with setenforce 1 and it worked with setenforce 0.
The only log entry in audit.log about failure was:
type=USER_AUTH msg=audit(1359570266.199:3008): pid=9453 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="luf" exe="/usr/bin/su" hostname=? addr=? terminal=? res=failed'

I tracked the problem to pam module pam_rootok.so (/var/log/secure).
setenfroce 0:
Jan 30 19:59:56 hurvajs su: pam_rootok(su:auth): root check succeeded

setenforce 1:
Jan 30 20:28:38 hurvajs su: pam_rootok(su:auth): root check failed

pam_rootok is compiled with selinux and the affected line is:
      if (is_selinux_enabled()<1 || checkPasswdAccess(PASSWD__ROOTOK)==0)

I got advice on linux@linux.cz to try:
allow cupsd_t self:passwd rootok;

This helps me. I think it should be logged in audit.log (when semodule -BD).

Version-Release number of selected component (if applicable):

How reproducible:
Redefine smb cups backend, define some fake printer and try to print on the printer.

Steps to Reproduce:
1. rm -f /usr/lib/cups/backend/smb
2. cat > /usr/lib/cups/backend/smb <<EOF

echo 'network smb "Unknown" "Windows Printer via SAMBA"'

/bin/su -c "/usr/bin/logger 'CUPS /bin/su works'" $2
3. load attached selinux policy
4. enable debug semodule -BD
5. setenforce 1
6. create cups printer using smb backend
7. print to the created printer
Actual results:
No information about failed rootok check in audit.log

Expected results:
Some audit.log entry of this form:
type=USER_AVC msg=audit(<timestamp>): avc: denied { rootok } for pid=.. comm=".." scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=... tclass=passwd

Additional info:
Comment 1 Daniel Walsh 2013-02-01 08:15:38 EST
This is a pam_rootok bug.  It needs to generate the SELinux AVC message.
Comment 2 Tomas Mraz 2013-02-01 13:03:10 EST

I'd like to implement similar code as in passwd. Is the check like this correct?

if ((status = getprevcon(&user_context)) < 0)
    return status;
status = selinux_check_access(user_context, user_context, "passwd", "passwd", NULL);

I'm just unsure about the getprevcon() call.
Comment 3 Daniel Walsh 2013-02-01 13:31:05 EST
Usually pam stack is called as passwd_t, but we want to determine which context called into passwd_t,  So getprevcon would tell us the context was unconfined_t, or sshd_t or staff_t.  Then we want to check to see if these users are allowed to change a password with providing their password.

In the case of pam, I think you would just use getcon()
Comment 4 Tomas Mraz 2013-07-12 02:52:13 EDT
*** Bug 965723 has been marked as a duplicate of this bug. ***
Comment 5 Fedora Update System 2013-07-12 04:23:13 EDT
pam-1.1.6-4.fc18 has been submitted as an update for Fedora 18.
Comment 6 Fedora Update System 2013-07-12 04:23:41 EDT
pam-1.1.6-12.fc19 has been submitted as an update for Fedora 19.
Comment 7 Fedora Update System 2013-07-12 21:51:10 EDT
Package pam-1.1.6-12.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 pam-1.1.6-12.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2013-07-13 23:31:16 EDT
pam-1.1.6-12.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2013-07-24 20:48:55 EDT
pam-1.1.6-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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