On 09/12/16 18:59, Christian Hesse wrote:
> Christian Hesse <l...@eworm.de> on Fri, 2016/12/09 18:37:
>> David Sommerseth <dav...@openvpn.net> on Wed, 2016/12/07 03:51:
>>> Commit c5931897ae8d663e7e introduced support for talking directly
>>> to the systemd service manager about the situation for the OpenVPN
>>> tunnel. This approach makes a lot of sense and is mostly the proper
>>> way to do it. But it was discovered that it breaks OpenVPN
>>> configurations using --chroot.
>>>
>>> The reason sd_notify() calls fails when using chroot() is that
>>> sd_notify() expects to have access to a file as declared in the
>>> $NOTIFY_SOCKET environment variable. It is the main systemd
>>> instance which is responsible to provide both the environment variable
>>> as well as the socket file sd_nodify() should use. When --chroot
>>> comes into play, the $NOTIFY_SOCKET file will not be available
>>> for OpenVPN any more.
>>>
>>> As things are getting close to the 2.4_rc2 release we will not dare
>>> to bring a too invasive fix. As well we need some time to discuss
>>> an approrpriate solution. So this intermediate fix will only
>>> provide a "successful start" message to the systemd service manager
>>> right before chroot() happens. This will at least resolve the issue
>>> in a safe and non-intrusive way.
>>>
>>> Signed-off-by: David Sommerseth <dav...@openvpn.net>
>>> ---
>>> src/openvpn/init.c | 22 +++++++++++++++++++++-
>>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
>>> index 74f1139..e47f0d4 100644
>>> --- a/src/openvpn/init.c
>>> +++ b/src/openvpn/init.c
>>> @@ -967,7 +967,27 @@ do_uid_gid_chroot (struct context *c, bool no_delay)
>>> if (c->options.chroot_dir)
>>> {
>>> if (no_delay)
>>> - platform_chroot (c->options.chroot_dir);
>>> + {
>>> +#ifdef ENABLE_SYSTEMD
>>> + /* If OpenVPN is started by systemd, the OpenVPN process
>>> needs
>>> + * to provide a preliminary status report to systemd. This
>>> is
>>> + * needed as $NOTIFY_SOCKET will not be available inside
>>> the
>>> + * chroot, which sd_notify()/sd_notifyf() depends on.
>>> + *
>>> + * This approach is the simplest and the most non-intrusive
>>> + * solution right before the 2.4_rc2 release.
>>> + *
>>> + * TODO: Consider altnernative solutions - bind mount?
>>> + * systemd does not grok OpenVPN configuration files, thus
>>> cannot
>>> + * have a sane way to know if OpenVPN will chroot or not
>>> and to
>>> + * which subdirectory it will chroot into.
>>> + */
>>> + sd_notifyf(0, "READY=1\n"
>>> + "STATUS=Entering chroot, most of the init completed
>>> successfully\n"
>>> + "MAINPID=%lu", (unsigned long) getpid());
>>> +#endif
>>> + platform_chroot (c->options.chroot_dir);
>>> + }
>>> else if (c->first_time)
>>> msg (M_INFO, "NOTE: chroot %s", why_not);
>>> }
>>
>> Looks good to me, so: ACKThanks! >> In long term we should think about a proper solution. Notification socket >> is /run/systemd/notify, so we would have to make that available from within >> the chroot. > > BTW, systemd used to use abstract sockets for notifications, which worked with > processes that chroot themselves. This was changed [0] in favor to > PrivateNetwork setting. Private network (in terms of systemd) is nothing we > can make use of, though. Obviously... :-p :) > Does it make sense to deny to chroot when running from systemd and instead > add some more security features to the systemd unit? Things like > ProtectSystem=strict, ProtectHome=true and friends. See systemd.exec(5) [1] > for details. Yes, I think this can make sense. I would also like to see more where things are headed in regards to namespaces (or app-container, if you want). If we can also isolate the openvpn process from as much as possible from the rest of the system (and find a solution for $HOME/.cert). But still that does provide some other challenges, though - like: What to do with script hooks and --plugin files? And especially other dependencies of shells/interpretors and shared objects they may depend on. Perhaps a discussion we could open up with the systemd team? -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
