Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user

[Gert Doering]

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

[Gert Doering]

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

[Gert Doering]

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]

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

[Simon Ruderich]

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

[Christian Hesse]

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

[Simon Ruderich]

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