[Openvpn-devel,1/2] systemd: extend CapabilityBoundingSet for auth_pam

Message ID 20180829142715.417-2-christian.ehrhardt@canonical.com
State Accepted
Headers show
Series
  • extend systemd service files for common use cases
Related show

Commit Message

Christian Ehrhardt Aug. 29, 2018, 2:27 p.m.
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(-)

Comments

David Sommerseth Aug. 30, 2018, 7:10 p.m. | #1
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?
Christian Ehrhardt Sept. 3, 2018, 6 a.m. | #2
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
>
>
>
>
>
David Sommerseth Sept. 3, 2018, 8:36 a.m. | #3
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.
David Sommerseth Sept. 3, 2018, 8:38 a.m. | #4
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)
Gert Doering Sept. 3, 2018, 8:45 a.m. | #5
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
Christian Ehrhardt Sept. 3, 2018, 8:47 a.m. | #6
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
>
>

Patch

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