Re: [Openvpn-devel] sbuild_wrapper: please unify service rules with openvpn repository
On Fri, Sep 7, 2018 at 12:24 PM David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:
> On 06/09/18 14:25, Samuli Seppänen wrote:
> > Hi,
> >
> > I maintain the Debian/Ubuntu packages for OpenVPN.
> >
> > Il 03/09/2018 12:24, Christian Ehrhardt ha scritto:
> >> Hi,
> >> the upstream provided .deb [1] e.g. for Ubuntu Xenial gets its service
> >> file from [2] which is outdated.
> >> This makes the upstream Repos [3] not being in sync
> >> I'd ask you to follow the main repo [4] on that to eliminate some Delta.
> >>
> >> In general I think that some of the packaging is outdated and
> >> sbuild_wrapper could fetch some more from Debian [5] and Ubuntu [6]
> >> (which match among each other on this)
> >
> > I've generally reused packaging files in OpenVPN packages provided by
> > the Ubuntu and Debian projects. In some cases, though, the packaging
> > files may be from a package meant for a (slightly) older operating
> > system version.
> >
> > Do you happen to have a diff at hand? I would not mind updating the
> > service files if the changes are fairly minor or fix a bug. But I don't
> > want to break setups that depend on the behavior of the outdated service
> > files.
>
> This is the location of the unit files which we really should use.
>
> <https://github.com/OpenVPN/openvpn/tree/master/distro/systemd>
>
Ack to that, this is also the place where we committed the fix to the
problem that made me aware of all this.
It should break anything if you have the openvpn-{client,server}@.service
> files packaged. It would actually fix a few bugs instead.
>
> I haven't checked the current state of what's in our .deb packages, but we
> should really ship the very latest at any time.
That is exactly what my report here is about, it currently ships very old
service files.
Not from the repo, nor the last ones from Debian/Ubuntu - older than both
actually
> And DO NOT ship the
> brokenness of openvpn.service and openvpn@.service ... those are not
> maintained by us and will make things work even worse;
Yep, I must admit I just "came by" and have no history on this.
But I'd assume we only have them around still for compatibility to old
things.
For anything new we also have
/lib/systemd/system/openvpn-client@.service
/lib/systemd/system/openvpn-server@.service
which are generated right out of the upstream source on build.
especially since
> openvpn 2.4.x and newer is systemd aware and integrates much better.
>
> > Also, we don't have packages for Ubuntu 18.04 yet. So using the
> > packaging files from Ubuntu's repositories makes perfect sense there and
> > can't break anything.
>
> Yes! Latest and greatest from our own sources. Always. ;-) And do not
> ship
> openvpn.service and openvpn@.service.
>
I'd totally agree that an upstream .deb does not need to consider the
Distributions past and could go without any of the old services.
To get much more recent packaging (with many fixes on that side) you could
start with what you find at
https://salsa.debian.org/debian/openvpn
And then drop the old debian/openvpn.install and debian/openvpn-generator
That should give you an otherwise up-to-date packaging with systemd
services purely from upstream sources.
IMHO You can use that for current/next Debian and Ubuntu alike.
The only Ubuntu difference is a (also historical) compat to set
--script-security 2 by default.
But just as above, this history doesn't matter to your .deb packages.
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Inc
>
>
>
> --
> 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
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] sbuild_wrapper: please unify service rules with openvpn repository
Hi, the upstream provided .deb [1] e.g. for Ubuntu Xenial gets its service file from [2] which is outdated. This makes the upstream Repos [3] not being in sync I'd ask you to follow the main repo [4] on that to eliminate some Delta. In general I think that some of the packaging is outdated and sbuild_wrapper could fetch some more from Debian [5] and Ubuntu [6] (which match among each other on this) P.S. those upstream debs are AFAIK built by [7] [1]: http://build.openvpn.net/debian/openvpn/release/2.4/pool/xenial/main/o/openvpn/ [2]: https://github.com/OpenVPN/sbuild_wrapper/tree/master/packaging/xenial/debian [3]: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos [4]: https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/openvpn-server%40.service.in [5]: https://salsa.debian.org/paelzer-guest/openvpn [6]: https://code.launchpad.net/~usd-import-team/ubuntu/+source/openvpn/+git/openvpn/+ref/ubuntu/devel [7]: https://github.com/OpenVPN/sbuild_wrapper -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- 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 applied] Re: systemd: extend CapabilityBoundingSet for auth_pam
On Mon, Sep 3, 2018 at 10:45 AM Gert Doering 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 > Acked-by: David Sommerseth > Message-Id: <20180829142715.417-2-christian.ehrha...@canonical.com> > URL: > https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17432.html > Signed-off-by: Gert Doering > 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 > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- 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 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
Re: [Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address
On Thu, Aug 30, 2018 at 1:38 AM David Sommerseth < open...@sf.lists.topphemmelig.net> wrote: > On 29/08/18 21:05, Christian Hesse wrote: > > Christian Ehrhardt on Wed, 2018/08/29 > > 16:27: > >> 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 > >> --- > >> 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 d1cc72cb..edace213 > 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 > >> 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 > > +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. > 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? > -- > kind regards, > > David Sommerseth > OpenVPN Inc > > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- 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 0/2] 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/openvpn-ser...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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
[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
[Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address
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 --- 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 d1cc72cb..edace213 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 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 -- 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
