extend systemd service files for common use cases

PATCH In review Christian Ehrhardt 4 participants 12 messages Aug 29, 2018 – Sep 3, 2018

Share & tools

Christian Ehrhardt

author

2018-08-29 14:27 UTC #0 lore raw

cover extend systemd service files for common use cases

Hi,
tracking down an Ubuntu bug I found what seemed to be a circular dependency around https://community.openvpn.net/openvpn/ticket/918

Realizing that your process requires the patches sent to the list I thought it might help to prep those.

I'd highly sak to consider the first change, the second I can understand the need but had no real use case myself so far.
To be able to discuss and also accept/nack them individually I split the changes.

Eventually I'd also want to sync the systemd service content in
https://github.com/OpenVPN/sbuild_wrapper to what is upstream. Therefore I was wondering how devel for that repo is done. After the discussion here resolves will a PR on github do it, or should this get a openvpn-devel ML post as well ?

Christian Ehrhardt (2):
systemd: extend CapabilityBoundingSet for auth_pam
systemd: extend CapabilityBoundingSet for learn-address

 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Signature · 1 line

2.17.1

Christian Ehrhardt

author

2018-08-29 14:27 UTC #1 lore raw

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[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 <[email protected]...>

---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

distro/systemd/[email protected]... +1 -1

index a8366a04..d1cc72cb 100644
@@ -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

Signature · 1 line

2.17.1

David Sommerseth

2018-08-30 19:10 UTC #2 lore raw

PATCH 1/2 systemd: extend CapabilityBoundingSet for auth_pam

Quoted 24 lines · Christian Ehrhardt

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 <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
distro/systemd/[email protected]... +0 -0
index a8366a04..d1cc72cb 100644

distro/systemd/[email protected]... Type=notify · line 14

Quoted 5 lines

distro/systemd/[email protected]... +1 -1

@@ -11,7 +11,7 @@ Type=notify
 PrivateTmp=true
 WorkingDirectory=/etc/openvpn/server
 [email protected]...@/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?

Signature · 4 lines

kind regards,

David Sommerseth
OpenVPN Inc

Christian Ehrhardt

author

2018-09-03 06:00 UTC #3 lore raw

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

Quoted 41 lines · David Sommerseth

Quoted 12 lines · Christian Ehrhardt
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.
Review
Quoted 8 lines
Fixes #918
Signed-off-by Christian Ehrhardt <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0
b/distro/systemd/[email protected]...
distro/systemd/[email protected]... Type=notify · line 13
Quoted 7 lines
index a8366a04..d1cc72cb 100644
distro/systemd/[email protected]... +0 -0
@@ -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
distro/systemd/[email protected]... Type=notify · line 14
Quoted 1 line
distro/systemd/[email protected]... +0 -1
-CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
distro/systemd/[email protected]... Type=notify · line 14
Quoted 1 line
distro/systemd/[email protected]... +1 -0
+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?

Quoted 8 lines

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()

Quoted 26 lines

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 · 3 lines

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

David Sommerseth

2018-09-03 08:36 UTC #4 lore raw

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

On 03/09/18 08:00, Christian Ehrhardt wrote:
[...snip...]

Quoted 68 lines

Quoted 1 line
-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

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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

David Sommerseth

Acked-by on v1 1/2

2018-09-03 08:38 UTC #5 lore raw

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

In reply to Christian Ehrhardt

Quoted 25 lines · Christian Ehrhardt

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 <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
distro/systemd/[email protected]... +0 -0
index a8366a04..d1cc72cb 100644

distro/systemd/[email protected]... Type=notify · line 17

Quoted 8 lines

distro/systemd/[email protected]... +1 -1

@@ -11,7 +11,7 @@ Type=notify
 PrivateTmp=true
 WorkingDirectory=/etc/openvpn/server
 [email protected]...@/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 <[email protected]...>

(The discussion is in a sub-thread, but keeping the ACK close to the patch for simplicity)

Signature · 4 lines

kind regards,

David Sommerseth
OpenVPN Inc

Gert Doering

2018-09-03 08:45 UTC #6 lore raw

[Openvpn-devel] [PATCH applied] Re: systemd: extend CapabilityBoundingSet for auth_pam

In reply to Christian Ehrhardt

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 <[email protected]...>
     Acked-by: David Sommerseth <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg17432.html
     Signed-off-by: Gert Doering <[email protected]...>

--
kind regards,

Gert Doering

Christian Ehrhardt

author

2018-09-03 08:47 UTC #7 lore raw

Re: [Openvpn-devel] [PATCH applied] Re: systemd: extend CapabilityBoundingSet for auth_pam

Quoted 7 lines · Gert Doering

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

Quoted 9 lines

     systemd: extend CapabilityBoundingSet for auth_pam

     Signed-off-by: Christian Ehrhardt <[email protected]...>
     Acked-by: David Sommerseth <[email protected]...>
     Message-Id: <[email protected]...>
     URL:
https://www.mail-archive.com/[email protected]/msg17432.html
     Signed-off-by: Gert Doering <[email protected]...>

Thank you both David and Gert!

I'll start a new thread about the unification of the deb provided with this
...

Quoted 5 lines

kind regards,
Gert Doering

Signature · 3 lines

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Christian Ehrhardt

author

2018-08-29 14:27 UTC #8 lore raw

PATCH 2/2 systemd: extend CapabilityBoundingSet for learn-address

In reply to Christian Ehrhardt

It seems a not too uncommon case that learn-address needs to recycle dnsmasq - to do so it would need CAP_KILL.

This was suggested on https://community.openvpn.net/openvpn/ticket/918

Signed-off-by Christian Ehrhardt <[email protected]...>

---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

distro/systemd/[email protected]... +1 -1

index d1cc72cb..edace213 100644
@@ -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 CAP_AUDIT_WRITE
+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_KILL
 LimitNPROC=10
 DeviceAllow=/dev/null rw
 DeviceAllow=/dev/net/tun rw

Signature · 1 line

2.17.1

Christian Hesse

2018-08-29 19:05 UTC #9 lore raw

Re: [Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address

Christian Ehrhardt <[email protected]...> on Wed, 2018/08/29 16:27:

Quoted 20 lines

It seems a not too uncommon case that learn-address needs to recycle dnsmasq - to do so it would need CAP_KILL.
This was suggested on https://community.openvpn.net/openvpn/ticket/918
Signed-off-by Christian Ehrhardt <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0
b/distro/systemd/[email protected]... index d1cc72cb..edace213 100644
distro/systemd/[email protected]... +0 -2
@@ -11,7 +11,7 @@ Type=notify
 PrivateTmp=true
 WorkingDirectory=/etc/openvpn/server
 [email protected]...@/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

Quoted 5 lines

CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE +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_KILL LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw

I do not like services being allowed to send signals to other processes. As dnsmasq supports a dbus interface... How about using that? For example to clear the dns cache of an instance started from Networkmanager:

dbus-send --system --print-reply \
--dest=org.freedesktop.NetworkManager.dnsmasq /uk/org/thekelleys/dnsmasq \
uk.org.thekelleys.ClearCache

Signature · 3 lines

main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

David Sommerseth

2018-08-29 23:38 UTC #10 lore raw

Re: [Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address

Quoted 32 lines · Christian Hesse

Christian Ehrhardt <[email protected]...> on Wed, 2018/08/29 16:27:
Quoted 20 lines
It seems a not too uncommon case that learn-address needs to recycle dnsmasq - to do so it would need CAP_KILL.
This was suggested on https://community.openvpn.net/openvpn/ticket/918
Signed-off-by Christian Ehrhardt <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0
b/distro/systemd/[email protected]... index d1cc72cb..edace213 100644
distro/systemd/[email protected]... +0 -2
@@ -11,7 +11,7 @@ Type=notify
 PrivateTmp=true
 WorkingDirectory=/etc/openvpn/server
 [email protected]...@/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
Quoted 5 lines
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE +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_KILL LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw
I do not like services being allowed to send signals to other processes. As dnsmasq supports a dbus interface... How about using that? For example to clear the dns cache of an instance started from Networkmanager:

Quoted 3 lines

dbus-send --system --print-reply \
--dest=org.freedesktop.NetworkManager.dnsmasq /uk/org/thekelleys/dnsmasq \
uk.org.thekelleys.ClearCache

+1 ... CAP_KILL privileges can too easily prepare the ground for DoS attacks.

The D-Bus approach above seems much saner and safer. Also because D-Bus gives a reasonable protection in regards to privilege escalation attacks. But you most likely need to prepare a D-Bus policy for dnsmasq though, to allow the openvpn user (or whatever user who will execute this script) access to the uk.org.thekelleys.ClearCache D-Bus method.

Signature · 4 lines

kind regards,

David Sommerseth
OpenVPN Inc

Christian Ehrhardt

author

2018-08-30 08:02 UTC #11 lore raw

Re: [Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address

Quoted 43 lines · David Sommerseth

Quoted 7 lines · Christian Hesse
Christian Ehrhardt <[email protected]...> on Wed, 2018/08/29 16:27:
Quoted 5 lines
It seems a not too uncommon case that learn-address needs to recycle dnsmasq - to do so it would need CAP_KILL.
This was suggested on https://community.openvpn.net/openvpn/ticket/918
Quoted 7 lines
Quoted 7 lines
Signed-off-by Christian Ehrhardt <[email protected]...>
---
 distro/systemd/[email protected]... | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0
b/distro/systemd/[email protected]... index d1cc72cb..edace213
100644
Quoted 7 lines
Quoted 7 lines
distro/systemd/[email protected]... +0 -1
@@ -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
Quoted 8 lines
Quoted 6 lines
distro/systemd/[email protected]... +0 -1
-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 +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_KILL LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw
I do not like services being allowed to send signals to other processes.
As
Quoted 5 lines
dnsmasq supports a dbus interface... How about using that? For example to clear the dns cache of an instance started from Networkmanager:
dbus-send --system --print-reply \
--dest=org.freedesktop.NetworkManager.dnsmasq /uk/org/thekelleys/dnsmasq
\
Quoted 1 line
uk.org.thekelleys.ClearCache
+1 ... CAP_KILL privileges can too easily prepare the ground for DoS attacks.

Quoted 8 lines

The D-Bus approach above seems much saner and safer. Also because D-Bus gives
a reasonable protection in regards to privilege escalation attacks. But you
most likely need to prepare a D-Bus policy for dnsmasq though, to allow the openvpn user (or whatever user who will execute this script) access to the uk.org.thekelleys.ClearCache D-Bus method.

I don't mind the KILL signal so much we can keep that off for another discussion.
I like the suggestion if the dbus signal, clearly worth a try for those with a matching setup.

After all my own thought of "umm KILL might be too much" is why I have split it :-)

What bug 918 was originally about and would have to be cleared soon is the CAP_AUDIT_WRITE.

So while we seem to agree we don't want/like CAP_KILL, could we add CAP_AUDIT_WRITE as submitted?

Quoted 8 lines

--
kind regards,
David Sommerseth
OpenVPN Inc

Signature · 3 lines

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd