Hide Forgot
Description of problem: time->Tue Nov 1 17:09:26 2011 type=SOCKADDR msg=audit(1320181766.296:106791): saddr=100075270000000000000000 type=SYSCALL msg=audit(1320181766.296:106791): arch=c000003e syscall=46 success=yes exit=16 a0=8 a1=7fff5a704bc0 a2=0 a3=4 items=0 ppid=24375 pid=24379 auid=500 uid=0 gid=502 euid=0 suid=0 fsuid=0 egid=502 sgid=502 fsgid=502 tty=pts1 ses=35 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320181766.296:106791): avc: denied { audit_control } for pid=24379 comm="sudo" capability=30 scontext=staff_u:staff_r:staff_sudo_t:s0-s15:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s15:c0.c1023 tclass=capability Version-Release number of selected component (if applicable): 3.7.19-120.el6.noarch How reproducible: always Steps to Reproduce: 1. login as a staff_r user (possibly using sssd as the authentication backend) 2. sudo -i -r sysadm_r 3. Actual results: succeeds but an AVC denial is thrown Expected results: no AVC denial Additional info: contents of /etc/pam.d/sudo #%PAM-1.0 auth include system-auth account include system-auth password include system-auth session required pam_tty_audit.so open_only enable=root session optional pam_keyinit.so revoke session required pam_limits.so contents of /etc/pam.d/system-auth auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=5 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth [default=die] pam_faillock.so authfail audit deny=5 auth required pam_deny.so account required pam_faillock.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 maxrepeats=3 minlen=12 lcredit=-2 ucredit=-2 dcredit=-2 ocredit=-2 difok=5 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_tty_audit.so disable=* enable=root session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
When SSSD is not running I see following AVC: ---- time->Wed Nov 2 09:47:08 2011 type=SYSCALL msg=audit(1320223628.352:69): arch=40000003 syscall=99 success=no exit=-13 a0=1c30ee8 a1=bfab5ad8 a2=46bbb4 a3=60001 items=0 ppid=1772 pid=1796 auid=502 uid=0 gid=502 euid=0 suid=0 fsuid=0 egid=502 sgid=502 fsgid=502 tty=tty1 ses=7 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s0 key=(null) type=AVC msg=audit(1320223628.352:69): avc: denied { getattr } for pid=1796 comm="sudo" name="/" dev=devtmpfs ino=4 scontext=staff_u:staff_r:staff_sudo_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem ----
The same AVC appears when SSSD is running.
Yes, I see the same issue.
I added fixes to Fedora.
I guess this should be allowed. But the audit_control is the one I have a problem with.
There could be something in the pam stack that is triggering this.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
The pam_tty_audit.so probably requires it. But I thought that the capability is different from the one required for auditctl command operation?
pam_tty_audit sends AUDIT_TTY_GET and AUDIT_TTY_SET messages through netlink.
Yes, I also think the pam_tty_audit module is the source of the CAP_AUDIT_CONTROL requirements.
But Steve, I thought we had added a different Capability for this? CAP_AUDIT_TTY or somesuch. Doesn't this access allow the sudo command to modify the audit rules using something like auditctl?
Yes, it does. No capability was added. I think the audit system needs some additional capabilities like CAP_SET_AUID and CAP_AUDIT_READ much worse than something for the TTY. But I could also see that, too.
According to SELinux policy... interface(`logging_set_loginuid',` allow $1 self:capability audit_control; allow $1 self:netlink_audit_socket { r_netlink_socket_perms nlmsg_relay }; ') interface(`logging_set_audit_parameters',` allow $1 self:capability { audit_write audit_control }; allow $1 self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay }; ') So you need audit_write and audit_control to change audit params. You need audit_write to set the loginuid, and I guess to turn on tty auditing.
CAP_AUDIT_WRITE is because sudo logs the commandline its passed. The control requirement is from TTY audit. Sudo should never set loginuid and if we had a capability for it, we could enforce that.
New capabilities need to be for very good reasons. If you want granularity use SELinux. New capabilities even remotely associated with existing ones are STRONGLY frowned upon upstream. aka, you cannot have CAP_SET_AUID. But we both know the right way to fix this is move to systemd and stop letting things set auid.
We did some analysis of this a while back. The kernel maintainer at the time said he would support a CAP_SET_AUID because the ability to set a loginuid does not mean that we additionally grant the right to delete all audit rules or change them in any way. The apps that set the loginuid _are_ part of the attack surface an unauthenticated user can abuse and possibly exploit. So, we would like to limit the damage that can be inflicted by those apps. As for CAP_AUDIT_READ, the ability to set TTY auditing should be distinct from being able to see the captured keystrokes for obvious reasons. But this is not solving this bz and should be discussed elsewhere.
We have rules in the policy for a while. Closing this as "CLOSED ERRATA".