Re: [Openvpn-devel] [PATCH 1/2] systemd: extend CapabilityBoundingSet for auth_pam
On 29/08/18 16:27, Christian Ehrhardt wrote: > Auth_pam will require audit writes or the connection will be rejected > as the plugin fails to initialize like: > openvpn[]: sudo: unable to send audit message > openvpn[]: sudo: pam_open_session: System error > openvpn[]: sudo: policy plugin failed session initialization > > See links from https://community.openvpn.net/openvpn/ticket/918 for > more. > > auth_pam is a common use case and capabilties for it should be allowed > by the .service file. > > Fixes: #918 > > Signed-off-by: Christian Ehrhardt > --- > distro/systemd/openvpn-ser...@.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/distro/systemd/openvpn-ser...@.service.in > b/distro/systemd/openvpn-ser...@.service.in > index a8366a04..d1cc72cb 100644 > --- a/distro/systemd/openvpn-ser...@.service.in > +++ b/distro/systemd/openvpn-ser...@.service.in > @@ -11,7 +11,7 @@ Type=notify > PrivateTmp=true > WorkingDirectory=/etc/openvpn/server > ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > --status-version 2 --suppress-timestamps --config %i.conf > -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 > LimitNPROC=10 > DeviceAllow=/dev/null rw > DeviceAllow=/dev/net/tun rw > Acked-By: David Sommerseth (The discussion is in a sub-thread, but keeping the ACK close to the patch for simplicity) -- 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
Re: [Openvpn-devel] [PATCH 1/2] systemd: extend CapabilityBoundingSet for auth_pam
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[]: sudo: unable to send audit message > openvpn[]: sudo: pam_open_session: System error > openvpn[]: 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
Re: [Openvpn-devel] [PATCH 1/2] systemd: extend CapabilityBoundingSet for auth_pam
On Thu, Aug 30, 2018 at 9:10 PM David Sommerseth < open...@sf.lists.topphemmelig.net> wrote: > On 29/08/18 16:27, Christian Ehrhardt wrote: > > Auth_pam will require audit writes or the connection will be rejected > > as the plugin fails to initialize like: > > openvpn[]: sudo: unable to send audit message > > openvpn[]: sudo: pam_open_session: System error > > openvpn[]: sudo: policy plugin failed session initialization > > > > See links from https://community.openvpn.net/openvpn/ticket/918 for > > more. > > > > auth_pam is a common use case and capabilties for it should be allowed > > by the .service file. > > > > Fixes: #918 > > > > Signed-off-by: Christian Ehrhardt > > --- > > distro/systemd/openvpn-ser...@.service.in | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/distro/systemd/openvpn-ser...@.service.in > b/distro/systemd/openvpn-ser...@.service.in > > index a8366a04..d1cc72cb 100644 > > --- a/distro/systemd/openvpn-ser...@.service.in > > +++ b/distro/systemd/openvpn-ser...@.service.in > > @@ -11,7 +11,7 @@ Type=notify > > PrivateTmp=true > > WorkingDirectory=/etc/openvpn/server > > ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > --status-version 2 --suppress-timestamps --config %i.conf > > -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[]: sudo: unable to send audit message openvpn[]: sudo: pam_open_session: System error openvpn[]: 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. 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. 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. 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
[Openvpn-devel] [PATCH 1/2] systemd: extend CapabilityBoundingSet for auth_pam
On 29/08/18 16:27, Christian Ehrhardt wrote: > Auth_pam will require audit writes or the connection will be rejected > as the plugin fails to initialize like: > openvpn[]: sudo: unable to send audit message > openvpn[]: sudo: pam_open_session: System error > openvpn[]: sudo: policy plugin failed session initialization > > See links from https://community.openvpn.net/openvpn/ticket/918 for > more. > > auth_pam is a common use case and capabilties for it should be allowed > by the .service file. > > Fixes: #918 > > Signed-off-by: Christian Ehrhardt > --- > distro/systemd/openvpn-ser...@.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/distro/systemd/openvpn-ser...@.service.in > b/distro/systemd/openvpn-ser...@.service.in > index a8366a04..d1cc72cb 100644 > --- a/distro/systemd/openvpn-ser...@.service.in > +++ b/distro/systemd/openvpn-ser...@.service.in > @@ -11,7 +11,7 @@ Type=notify > PrivateTmp=true > WorkingDirectory=/etc/openvpn/server > ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > --status-version 2 --suppress-timestamps --config %i.conf > -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 did a little search the PAM error which occurs (audit_log_acct_message() failed: Operation not permitted), and I could find a similar error in Fedora 8 (which is from 2007-2008). But from what I can grasp, this doesn't sound directly related to this issue we're seeing here. And this was around PAM version 0.99. My Debian test VM uses pam-1.1.8-3.6, RHEL-7 pam-1.1.8-22 and Fedora 28 pam-1.3.1-1. Since both my Debian VM and my RHEL-7 install uses essentially quite similar PAM releases Debian must be doing something different ... but what? I even verified that all distros are compiled with libaudit, and they are. Anyone got a clue? -- 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
[Openvpn-devel] [PATCH 1/2] systemd: extend CapabilityBoundingSet for auth_pam
Auth_pam will require audit writes or the connection will be rejected as the plugin fails to initialize like: openvpn[]: sudo: unable to send audit message openvpn[]: sudo: pam_open_session: System error openvpn[]: sudo: policy plugin failed session initialization See links from https://community.openvpn.net/openvpn/ticket/918 for more. auth_pam is a common use case and capabilties for it should be allowed by the .service file. Fixes: #918 Signed-off-by: Christian Ehrhardt --- distro/systemd/openvpn-ser...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/distro/systemd/openvpn-ser...@.service.in b/distro/systemd/openvpn-ser...@.service.in index a8366a04..d1cc72cb 100644 --- a/distro/systemd/openvpn-ser...@.service.in +++ b/distro/systemd/openvpn-ser...@.service.in @@ -11,7 +11,7 @@ Type=notify PrivateTmp=true WorkingDirectory=/etc/openvpn/server ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf -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 LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw -- 2.17.1 -- 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
