| Message ID | 20180829142715.417-2-christian.ehrhardt@canonical.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | extend systemd service files for common use cases | expand |
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[1111]: sudo: unable to send audit message > openvpn[1111]: sudo: pam_open_session: System error > openvpn[1111]: 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 <christian.ehrhardt@canonical.com> > --- > distro/systemd/openvpn-server@.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in > index a8366a04..d1cc72cb 100644 > --- a/distro/systemd/openvpn-server@.service.in > +++ b/distro/systemd/openvpn-server@.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?
On Thu, Aug 30, 2018 at 9:10 PM David Sommerseth < openvpn@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[1111]: sudo: unable to send audit message > > openvpn[1111]: sudo: pam_open_session: System error > > openvpn[1111]: 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 <christian.ehrhardt@canonical.com> > > --- > > distro/systemd/openvpn-server@.service.in | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/distro/systemd/openvpn-server@.service.in > b/distro/systemd/openvpn-server@.service.in > > index a8366a04..d1cc72cb 100644 > > --- a/distro/systemd/openvpn-server@.service.in > > +++ b/distro/systemd/openvpn-server@.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[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. 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 explanation why/how this is needed? 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 > > > > >
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.
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[1111]: sudo: unable to send audit message > openvpn[1111]: sudo: pam_open_session: System error > openvpn[1111]: 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 <christian.ehrhardt@canonical.com> > --- > distro/systemd/openvpn-server@.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in > index a8366a04..d1cc72cb 100644 > --- a/distro/systemd/openvpn-server@.service.in > +++ b/distro/systemd/openvpn-server@.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 <davids@openvpn.net> (The discussion is in a sub-thread, but keeping the ACK close to the patch for simplicity)
Your patch has been applied to the master and release/2.4 branch.
commit a564781cfd9912d0f755394d1fa610706d93e707 (master)
commit 7cc372c7f6b4dcc20533433a20dfd5a95f117146 (release/2.4)
Author: Christian Ehrhardt
Date: Wed Aug 29 16:27:14 2018 +0200
systemd: extend CapabilityBoundingSet for auth_pam
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20180829142715.417-2-christian.ehrhardt@canonical.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17432.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
On Mon, Sep 3, 2018 at 10:45 AM Gert Doering <gert@greenie.muc.de> wrote: > Your patch has been applied to the master and release/2.4 branch. > > commit a564781cfd9912d0f755394d1fa610706d93e707 (master) > commit 7cc372c7f6b4dcc20533433a20dfd5a95f117146 (release/2.4) > Author: Christian Ehrhardt > Date: Wed Aug 29 16:27:14 2018 +0200 > > systemd: extend CapabilityBoundingSet for auth_pam > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> > Acked-by: David Sommerseth <davids@openvpn.net> > Message-Id: <20180829142715.417-2-christian.ehrhardt@canonical.com> > URL: > https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17432.html > Signed-off-by: Gert Doering <gert@greenie.muc.de> > Thank you both David and Gert! I'll start a new thread about the unification of the deb provided with this ... -- > kind regards, > > Gert Doering > >
diff --git a/distro/systemd/openvpn-server@.service.in b/distro/systemd/openvpn-server@.service.in index a8366a04..d1cc72cb 100644 --- a/distro/systemd/openvpn-server@.service.in +++ b/distro/systemd/openvpn-server@.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
Auth_pam will require audit writes or the connection will be rejected as the plugin fails to initialize like: openvpn[1111]: sudo: unable to send audit message openvpn[1111]: sudo: pam_open_session: System error openvpn[1111]: 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 <christian.ehrhardt@canonical.com> --- distro/systemd/openvpn-server@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)