Re: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

[David Sommerseth]

On 09/12/16 18:59, Christian Hesse wrote:
> Christian Hesse  on Fri, 2016/12/09 18:37:
>> David Sommerseth  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 
>>> ---
>>>  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: ACK

Thanks!

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

Re: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

[Christian Hesse]

Christian Hesse  on Fri, 2016/12/09 18:37:
> David Sommerseth  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 
> > ---
> >  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: ACK
> 
> 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.

[0]
https://github.com/systemd/systemd/commit/7181dbdb2e3112858d62bdaea4f0ad2ed685ccba
[1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
-- 
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);}


pgpllYZqjGzAH.pgp
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

Re: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

[Christian Hesse]

David Sommerseth  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 
> ---
>  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: ACK

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, feel free to CC me on systemd related topics.
-- 
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);}


pgpzdl_cITWjn.pgp
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

[Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

[David Sommerseth]

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 
---
 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);
}
-- 
1.8.3.1


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