Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Hi, On Tue, Apr 24, 2018 at 4:16 PM, Christian Hesse wrote: > Antonio Quartulli on Tue, 2018/04/24 23:08: >> OTOH I understand that there are people that don't care about having a >> working tunnel reconfiguration and are fine with starting openvpn as >> root (and then dropping privileges). >> >> For these people, adding the above capabilities results in giving the >> openvpn process more power than before. >> >> Maybe users willing to adopt this stricter behaviour should have a knob >> somewhere that will enable the usual >> run-as-root-and-then-drop-priv-with-no-caps? > > NAK. :-p > > I think the solution for this dilemma is pretty easy: I should strip the part > from my patch that disables user switching when started from systemd. We can > start as user "openvpn" any way - as long as the process has capabilities > CAP_SETGID and CAP_SETUID it still can switch user context and drop > privileges I'm not yet up to speed with capabilities in recent versions of linux, but some of the proposed ideas look unsafe to me. In particular: Be careful setting CAP_SETUID on the file without code changes. Once that is set, starting as root and dropping privileges is not the same as starting as non-root and dropping privileges. In the former case all capabilities will get cleared (which is good) but not so in the latter case. The process can elevate back to root in the second case which is bad. We'll need to add some code to clear all caps before the setuid() call to do this safely. Also, if the server is using pam for user-auth, the forked copy needs to run as root which is currently handled by forking before the setuid call. Need to consider how that will work with capabilities without handing out cap_setuid to all. As Gert said, looks like we are jumping the gun here. First thoroughly test and evaluate the nuances of the use of capabilities in context before deciding on how to make use of it. Selva -- 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/1] systemd: run openvpn with dedicated user
Hi, On Mon, Apr 23, 2018 at 11:28:13AM +0200, Christian Hesse wrote: > @@ -1151,6 +1151,14 @@ do_uid_gid_chroot(struct context *c, bool no_delay) > /* set user and/or group if we want to setuid/setgid */ > if (c0->uid_gid_specified) > { > +#ifdef ENABLE_SYSTEMD > +if (sd_notify(0, "READY=0") > 0 && getuid() != 0) > +{ > +msg(M_INFO, "NOTE: Running from systemd with non-root uid, > skipping downgrade"); > +return; > +} > +#endif > + > if (no_delay) This is not a good approach. If you run with a limited capability model, then just do not set "setuid" in your config files, and document clearly that this is incompatible. But do not litter general-purpose code with #ifdef SYSTEMD bits that will randomly ignore user-specified options. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Hi, On Tue, Apr 24, 2018 at 10:16:36PM +0200, Christian Hesse wrote: > No need to have root involved. Sounds good? This is not our traditional approach of "give people rope to hang themselves if they want so". So I'll NAK any patch that *requires* use of systemd, capabilities and non-root users on Linux. As an option, welcome. (I'm not finding a really good reason right now why I would need to run openvpn as root which couldn't be done with CAP_NET_ADMIN, so the recommendation should certainly be "use non-root" - but then, we're not enforcing --setuid today either) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Hi, On Tue, Apr 24, 2018 at 11:08:22PM +0800, Antonio Quartulli wrote: > Generally speaking I believe that openvpn, as a VPN and partly routing > daemon, should be allowed to run with CAP_NET_ADMIN set as it enables > more features (tunnel reconfiguration to start with). If we go there, we might consider dropping all non-default capabilities before running external programs (--up, --client-connect, ...) This patch is a bit "gallopping ahead", though - it needs a somewhat more solid agreement on our privilege model before modifying systemd unit files... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Antonio Quartulli on Tue, 2018/04/24 23:08: > OTOH I understand that there are people that don't care about having a > working tunnel reconfiguration and are fine with starting openvpn as > root (and then dropping privileges). > > For these people, adding the above capabilities results in giving the > openvpn process more power than before. > > Maybe users willing to adopt this stricter behaviour should have a knob > somewhere that will enable the usual > run-as-root-and-then-drop-priv-with-no-caps? NAK. :-p I think the solution for this dilemma is pretty easy: I should strip the part from my patch that disables user switching when started from systemd. We can start as user "openvpn" any way - as long as the process has capabilities CAP_SETGID and CAP_SETUID it still can switch user context and drop privileges. So users have two options: keep the process running as user "openvpn" with capabilities for more flexibility or switch to unprivileged user for more security. No need to have root involved. Sounds good? -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];) putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);} pgpCuVux2kjDG.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Hi, On 24/04/18 21:08, Simon Ruderich wrote: >> I do not agree that the process is running with root privileges. It has some >> extra capabilities, but it can not kill processes, fork away and change >> cgroups, etc. >> IMHO that is what we want to achieve. > > I disagree. A process with CAP_DAC_OVERRIDE can read/write > _every_ file on the system (man 7 capabilities)! This equals root > privileges. Even CAP_NET_ADMIN is very powerful as it allows > modifying the firewall which might give access to sensitive > services which are normally not exposed. > >> For this patch I took the current set of capabilities and stripped CAP_SETGID >> and CAP_SETUID for the netlink version. Whether or not the other capabilities >> are required should be discussed independently. Wondering why we have >> CAP_DAC_OVERRIDE in our capability capability set... That looks suspicious >> indeed. > > Even with CAP_DAC_OVERRIDE stripped this change keeps openvpn > running with (much) more privileges than before. Is this > desirable? I think it depends on your perspective. What Christian says is that with this patch: 1) you can start openvpn as non-root directly (impossible right now) 2) you have full support for tunnel reconfiguration even when running as non-root (people willing to achieve this now must start and keep openvpn running as root) I consider both points above steps forward towards a better security model for OpenVPN. OTOH I understand that there are people that don't care about having a working tunnel reconfiguration and are fine with starting openvpn as root (and then dropping privileges). For these people, adding the above capabilities results in giving the openvpn process more power than before. Maybe users willing to adopt this stricter behaviour should have a knob somewhere that will enable the usual run-as-root-and-then-drop-priv-with-no-caps? Generally speaking I believe that openvpn, as a VPN and partly routing daemon, should be allowed to run with CAP_NET_ADMIN set as it enables more features (tunnel reconfiguration to start with). Maybe clients should run with the caps by default while servers should be launched with the original behaviour? Not sure, honestly. Cheers, -- Antonio Quartulli signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
On Tue, Apr 24, 2018 at 12:03:37PM +0200, Christian Hesse wrote: > The above snippet holds code for both, netlink and iproute2 versions. > > The iproute2 version (that is what is used currently) uses systemd option > "CapabilityBoundingSet" to limit the capabilities to the given set. If > configured openvpn will drop privileges after setup. > > With netlink and my patch on top we go the other way: The process runs (and > is started) with user "openvpn". To grant required privileges we use > systemd option "AmbientCapabilities" and give capabilities to the process. > The process keeps these capabilities, but that's a benefit: The process > survives a reconnect that requires configuration changes and shuts down > cleanly (takes down routes and addresses). Hello Christian, Thanks for the confirmation, that's what I assumed. > I do not agree that the process is running with root privileges. It has some > extra capabilities, but it can not kill processes, fork away and change > cgroups, etc. > IMHO that is what we want to achieve. I disagree. A process with CAP_DAC_OVERRIDE can read/write _every_ file on the system (man 7 capabilities)! This equals root privileges. Even CAP_NET_ADMIN is very powerful as it allows modifying the firewall which might give access to sensitive services which are normally not exposed. > For this patch I took the current set of capabilities and stripped CAP_SETGID > and CAP_SETUID for the netlink version. Whether or not the other capabilities > are required should be discussed independently. Wondering why we have > CAP_DAC_OVERRIDE in our capability capability set... That looks suspicious > indeed. Even with CAP_DAC_OVERRIDE stripped this change keeps openvpn running with (much) more privileges than before. Is this desirable? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Simon Ruderich on Tue, 2018/04/24 10:38: > I haven't followed the netlink conversion in detail, so please > tell me if the following was already discussed and I've just > missed it. No, it has not been discussed and needs a review. > On Mon, Apr 23, 2018 at 11:28:13AM +0200, Christian Hesse wrote: > > if ENABLE_SYSTEMD > > +if ENABLE_IPROUTE > > +SYSTEMD_USER=root > > +SYSTEMD_CAPS_OPTION=CapabilityBoundingSet > > +SYSTEMD_CAPS_VALUES=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > > CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE +else > > +SYSTEMD_USER=openvpn > > +SYSTEMD_CAPS_OPTION=AmbientCapabilities > > +SYSTEMD_CAPS_VALUES=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > > CAP_NET_RAW CAP_SYS_CHROOT CAP_DAC_OVERRIDE > > Are those capabilities dropped after initialization? If they are > not this sounds like a serious issue as the process is basically > running as root even if it's using another user (CAP_NET_ADMIN > and CAP_DAC_OVERRIDE). Or am I missing something here? > > Regarding the netlink change in general: From what I understand > it means that openvpn will always run with CAP_NET_ADMIN > capabilities. Is this correct? If so, this sounds like it > requires much more privileges than before for the normal > operation (unless I misunderstand the current setup - to my > knowledge it only requires a normal user after setup and no > further capabilities or privileges once setup/connected). The above snippet holds code for both, netlink and iproute2 versions. The iproute2 version (that is what is used currently) uses systemd option "CapabilityBoundingSet" to limit the capabilities to the given set. If configured openvpn will drop privileges after setup. With netlink and my patch on top we go the other way: The process runs (and is started) with user "openvpn". To grant required privileges we use systemd option "AmbientCapabilities" and give capabilities to the process. The process keeps these capabilities, but that's a benefit: The process survives a reconnect that requires configuration changes and shuts down cleanly (takes down routes and addresses). I do not agree that the process is running with root privileges. It has some extra capabilities, but it can not kill processes, fork away and change cgroups, etc. IMHO that is what we want to achieve. For this patch I took the current set of capabilities and stripped CAP_SETGID and CAP_SETUID for the netlink version. Whether or not the other capabilities are required should be discussed independently. Wondering why we have CAP_DAC_OVERRIDE in our capability capability set... That looks suspicious indeed. -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];) putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);} pgpOWT9rvHVUt.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user
Hello, I haven't followed the netlink conversion in detail, so please tell me if the following was already discussed and I've just missed it. On Mon, Apr 23, 2018 at 11:28:13AM +0200, Christian Hesse wrote: > if ENABLE_SYSTEMD > +if ENABLE_IPROUTE > +SYSTEMD_USER=root > +SYSTEMD_CAPS_OPTION=CapabilityBoundingSet > +SYSTEMD_CAPS_VALUES=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE > +else > +SYSTEMD_USER=openvpn > +SYSTEMD_CAPS_OPTION=AmbientCapabilities > +SYSTEMD_CAPS_VALUES=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > CAP_NET_RAW CAP_SYS_CHROOT CAP_DAC_OVERRIDE Are those capabilities dropped after initialization? If they are not this sounds like a serious issue as the process is basically running as root even if it's using another user (CAP_NET_ADMIN and CAP_DAC_OVERRIDE). Or am I missing something here? Regarding the netlink change in general: From what I understand it means that openvpn will always run with CAP_NET_ADMIN capabilities. Is this correct? If so, this sounds like it requires much more privileges than before for the normal operation (unless I misunderstand the current setup - to my knowledge it only requires a normal user after setup and no further capabilities or privileges once setup/connected). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel