[strongSwan-dev] [PATCH] Allow strongSwan to be spawned as non-root user. (patch file attached)

[Micah Morton]

>
> Thanks for the patch.  I think this is mostly a legacy issue (i.e. when
> starting the daemon via starter).  charon and it's derivatives don't
> check whether they are running as root, so it's possible to start them
> as any user given the appropriate capabilities are e.g. set on the
> executable.
>

Thanks for the info, didn't realize starting via starter was the legacy way
of doing it :)


> > This patch allows for giving strongSwan only the runtime capabilities it
> > needs, rather than full root privileges.
>
> Does this provide a particular advantage over starting as root and then
> change to a non-root user/group while keeping the required capabilities?
>  Do you build with --with-capabilities?
>

Yes, the current use case we are looking to support is one where starter
itself is
spawned by a non-root user, and we are looking to avoid using any kind of
setuid
bit or file permissions on the starter executable, but rather stick to
using runtime
capabilities only.


> > Adds preprocessor directives which allow strongSwan to be configured to

>  1) start up as a non-root user
>
> I guess we could also just remove that check.  However, an #ifdef is OK
> too, but perhaps name it differently (e.g. STARTER_ALLOW_NON_ROOT),
> because it's specific to starter and it doesn't "start" the daemon
> non-root, it just allows starting starter non-root.
>

I agree.


>
> >  2) avoid modprobe()'ing IPsec kernel modules into the kernel, which
> >     would normally require root or CAP_SYS_MODULE
>
> This stuff is not required anyway, it's just a relict from the early
> days of strongSwan.  Is it a problem, though, if modprobe is called?
> (The exit status is not checked.)
>

>From a system/debugging perspective its preferable to cut down on noisy
failed
syscalls (e.g. avoid confusion when using Linux syscall auditing to
diagnose an
issue), but I agree that a failed modprobe() call isn't harmful beyond this.


>
> > Additionally, some small mods to charon/libstrongswan ensure that charon
> > supports starting as a non-root user.
>
> Looks OK.  I've pushed the patch with some minor changes to the
> starter-non-root branch.  Let me know if that works for you.
>

Awesome! Thanks.

Should I submit another patch for the suggested revisions to the starter
patch (e.g. #ifdef macro name change)?


On Fri, Apr 20, 2018 at 9:40 AM, Micah Morton <mortonm at chromium.org> wrote:

> Thanks for the patch.  I think this is mostly a legacy issue (i.e. when
>> starting the daemon via starter).  charon and it's derivatives don't
>> check whether they are running as root, so it's possible to start them
>> as any user given the appropriate capabilities are e.g. set on the
>> executable.
>>
>
> Thanks for the info, didn't realize starting via starter was the legacy
> way of doing it :)
>
>
>> > This patch allows for giving strongSwan only the runtime capabilities it
>> > needs, rather than full root privileges.
>>
>> Does this provide a particular advantage over starting as root and then
>> change to a non-root user/group while keeping the required capabilities?
>>  Do you build with --with-capabilities?
>>
>
> Yes, the current use case we are looking to support is one where starter
> itself is
> spawned by a non-root user, and we are looking to avoid using any kind of
> setuid
> bit or file permissions on the starter executable, but rather stick to
> using runtime
> capabilities only.
>
>
>> > Adds preprocessor directives which allow strongSwan to be configured to
>
> >  1) start up as a non-root user
>>
>> I guess we could also just remove that check.  However, an #ifdef is OK
>> too, but perhaps name it differently (e.g. STARTER_ALLOW_NON_ROOT),
>> because it's specific to starter and it doesn't "start" the daemon
>> non-root, it just allows starting starter non-root.
>>
>
> I agree.
>
>
>>
>> >  2) avoid modprobe()'ing IPsec kernel modules into the kernel, which
>> >     would normally require root or CAP_SYS_MODULE
>>
>> This stuff is not required anyway, it's just a relict from the early
>> days of strongSwan.  Is it a problem, though, if modprobe is called?
>> (The exit status is not checked.)
>>
>
> From a system/debugging perspective its preferable to cut down on noisy
> failed
> syscalls (e.g. avoid confusion when using Linux syscall auditing to
> diagnose an
> issue), but I agree that a failed modprobe() call isn't harmful beyond
> this.
>
>
>>
>> > Additionally, some small mods to charon/libstrongswan ensure that charon
>> > supports starting as a non-root user.
>>
>> Looks OK.  I've pushed the patch with some minor changes to the
>> starter-non-root branch.  Let me know if that works for you.
>>
>
> Awesome! Thanks.
>
> Should I submit another patch for the suggested revisions to the starter
> patch (e.g. #ifdef macro name change)?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20180420/1efe3dc3/attachment.html>