Bug 906679

Summary: Failed passwd rootok action isn't logged into audit.log
Product: [Fedora] Fedora Reporter: Ludek Finstrle <luf>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 18CC: dominick.grift, dwalsh, mgrepl, tmraz, tristan.santore
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: pam-1.1.6-4.fc18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-14 03:31:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
selinux policy with passwd rootok commented out none

Description Ludek Finstrle 2013-02-01 08:24:20 UTC
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:
#ifdef WITH_SELINUX
      if (is_selinux_enabled()<1 || checkPasswdAccess(PASSWD__ROOTOK)==0)
#endif

I got advice on linux 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):
cups-1.5.4-20.fc18
pam-1.1.6-3.fc18
selinux-policy-3.11.1-73.fc18


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
#!/bin/sh

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

/bin/su -c "/usr/bin/logger 'CUPS /bin/su works'" $2
EOF
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 13:15:38 UTC
This is a pam_rootok bug.  It needs to generate the SELinux AVC message.

Comment 2 Tomas Mraz 2013-02-01 18:03:10 UTC
Dan,

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 18:31:05 UTC
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 06:52:13 UTC
*** Bug 965723 has been marked as a duplicate of this bug. ***

Comment 5 Fedora Update System 2013-07-12 08:23:13 UTC
pam-1.1.6-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/pam-1.1.6-4.fc18

Comment 6 Fedora Update System 2013-07-12 08:23:41 UTC
pam-1.1.6-12.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/pam-1.1.6-12.fc19

Comment 7 Fedora Update System 2013-07-13 01:51:10 UTC
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:
https://admin.fedoraproject.org/updates/FEDORA-2013-12889/pam-1.1.6-12.fc19
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2013-07-14 03:31:16 UTC
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-25 00:48:55 UTC
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.