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


Attachment: 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

Reply via email to