On 03/09/18 08:00, Christian Ehrhardt wrote: [...snip...] > > -CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE > > +CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE > CAP_AUDIT_WRITE > > CAP_AUDIT_WRITE sounds safe to add. But I really need to get a better > understanding *why* this is needed, when OpenVPN itself don't need this. > What > is it in the PAM code paths which triggers this requirement and why? > > There might be perfect valid reasons, but we can't just blindly jump into > "Yes, we need it" without a good understanding of why. > > I have run tests on RHEL-7, Fedora 28 and some older Debian 8-9-ish-sid > release. I only stumble upon this issue on Debian. So what is it Debian > (and > thus Ubuntu) does which causes this error? > > > I can only assume, but doing so I could think of the default way sudo is set > up for being the reason. > Looking at the messages: > openvpn[1111]: sudo: unable to send audit message > openvpn[1111]: sudo: pam_open_session: System error > openvpn[1111]: sudo: policy plugin failed session initialization > > It uses sudo for the callout in the openvpn configuration, > learn-address "/usr/bin/sudo -u root > /etc/openvpn/scripts/ndp-proxy-setup.sh" > and the error seems to be related to actually sudo (in the openvpn context) > being unable to log it's action. > Now by default in Ubuntu/Debian there is /var/log/auth.log which will log any > sudo activity. > > In a little experiment I got to the same errors by dropping that capabilty: > running "sudo id" as-is > $ sudo capsh -- -c "/usr/bin/sudo /usr/bin/id" > uid=0(root) gid=0(root) groups=0(root) > > There are log entries for this like: > sudo[4784]: paelzer : TTY=pts/1 ; PWD=/home/paelzer ; USER=root ; > COMMAND=/sbin/capsh -- -c /usr/bin/sudo /usr/bin/id > sudo[4784]: pam_unix(sudo:session): session opened for user root by > paelzer(uid=0) > sudo[4785]: root : TTY=pts/1 ; PWD=/home/paelzer ; USER=root ; > COMMAND=/usr/bin/id > sudo[4785]: pam_unix(sudo:session): session opened for user root by > paelzer(uid=0) > > But now in contrast doing the same with audit_write dropped > $ sudo capsh --drop="cap_audit_write" -- -c "/usr/bin/sudo /usr/bin/id" > sudo: unable to send audit message > sudo: pam_open_session: System error > sudo: policy plugin failed session initialization > > And on the log side we will recognize some known messages: > sudo[4797]: paelzer : TTY=pts/1 ; PWD=/home/paelzer ; USER=root ; > COMMAND=/sbin/capsh --drop=cap_audit_write -- -c /usr/bin/sudo /usr/bin/id > sudo[4797]: pam_unix(sudo:session): session opened for user root by > paelzer(uid=0) > sudo[4798]: root : TTY=pts/1 ; PWD=/home/paelzer ; USER=root ; > COMMAND=/usr/bin/id > sudo[4798]: PAM audit_log_acct_message() failed: Operation not permitted > sudo[4798]: pam_unix(sudo:session): session opened for user root by > paelzer(uid=0) > sudo[4798]: root : pam_open_session: System error ; TTY=pts/1 ; > PWD=/home/paelzer ; USER=root ; COMMAND=/usr/bin/id > sudo[4797]: pam_unix(sudo:session): session closed for user root > > > On RH sudo isn't even installed by default, it is just not their common way to > do these things.
This used to be the case, but sudo is more widely used these days. As FreeIPA is being used more and more widely, which has a neat centralized sudo management, the advantages of sudo becomes more apparent - also on Fedora/RHEL. I even see more and more blog posts where sudo is used, and even anaconda has for some time allowed system installation without setting the root password and can create a user account with sudo access. > I also haven't seen anything like /var/log/auth.log on a bare fedora system > while you'll always find it configured on Debian/Ubuntu. It's in /var/log/secure and /var/log/audit/audit.log. The former is what is auth.log on Deb/Ubu, the audit.log is more commonly related to more fine grained audit logging from other aspects of the authentication/security mechanisms. And the log format is also very different. > Maybe the callout isn't even done with sudo in the RH/Fedora case, I'd assume > that is (one of?) the reasons for the different behavior. Both your sudo tests works out-of-the box on my RHEL-7 system, even the one with "--drop=cap_audit_write" - but with a warning printed to the terminal. But it executes without failure. $ sudo capsh --drop="cap_audit_write" -- -c "/usr/bin/sudo /usr/bin/id" sudo: unable to send audit message uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Here's some details from both /var/log/secure ... sudo: testuser : TTY=pts/12 ; PWD=/home/testuser ; USER=root ; COMMAND=/sbin/capsh --drop=cap_audit_write -- -c /usr/bin/sudo /usr/bin/id sudo: testuser : TTY=pts/12 ; PWD=/home/testuser ; USER=root ; COMMAND=/usr/bin/id ... and /var/log/audit/audit.log: type=CRED_REFR msg=audit(1535960094.675:11847): pid=24379 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_START msg=audit(1535960094.676:11848): pid=24379 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_END msg=audit(1535960094.695:11849): pid=24379 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=CRED_DISP msg=audit(1535960094.695:11850): pid=24379 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' To compare that against running 'sudo capsh' without --drop: $ sudo capsh -- -c "/usr/bin/sudo /usr/bin/id" uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 From /var/log/secure sudo: testuser : TTY=pts/12 ; PWD=/home/testuser ; USER=root ; COMMAND=/usr/bin/id From /var/log/audit/audit.log: type=USER_CMD msg=audit(1535962169.863:11921): pid=27464 uid=2001 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/testuser" cmd=6361707368202D2D202D63202F7573722F62696E2F7375646F202F7573722F62696E2F6964 terminal=pts/12 res=success' type=CRED_REFR msg=audit(1535962169.863:11922): pid=27464 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_START msg=audit(1535962169.864:11923): pid=27464 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_CMD msg=audit(1535962169.880:11924): pid=27465 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/testuser" cmd="/usr/bin/id" terminal=pts/12 res=success' type=CRED_REFR msg=audit(1535962169.880:11925): pid=27465 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_START msg=audit(1535962169.882:11926): pid=27465 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_END msg=audit(1535962169.886:11927): pid=27465 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=CRED_DISP msg=audit(1535962169.887:11928): pid=27465 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=USER_END msg=audit(1535962169.889:11929): pid=27464 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' type=CRED_DISP msg=audit(1535962169.889:11930): pid=27464 uid=0 auid=2001 ses=634 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/12 res=success' So the audit.log is much more verbose with CAP_AUDIT_WRITE privileges. > I'd think sudo is a fairly common way to set things up, I'd also assume that > its logging is recommended default and thereby Debian/Ubuntu but probably also > some other distributions would benefit from adding CAP_AUDIT_WRITE > Does this suffice as explanation why/how this is needed? Partially. I think there must be a difference in how PAM is configured on Deb/Ubu, where not being able to log to the audit is not considered acceptable and the access is denied. On Fedora/RHEL, audit logging errors are accepted. I can see arguments for both sides of this behaviour, but that is an entirely different discussion (and not so interesting for OpenVPN). Next, by adding the CAP_AUDIT_WRITE privilege, I do see more verbose logging in /var/log/audit/audit.log when OpenVPN performs the PAM authentication. As we now got a smoking gun to why CAP_AUDIT_WRITE is needed on Debian/Ubuntu, and we can see a benefit of having it on other distros, I'm can give this an ACK. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel