<div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the patch.  I think this is mostly a legacy issue (i.e. when<br>starting the daemon via starter).  charon and it's derivatives don't<br>check whether they are running as root, so it's possible to start them<br>as any user given the appropriate capabilities are e.g. set on the<br>executable.<br></blockquote><div> </div></span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Thanks for the info, didn't realize starting via starter was the legacy way of doing it :) </div><span class="gmail-im" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>> This patch allows for giving strongSwan only the runtime capabilities it<br>> needs, rather than full root privileges.<br><br></span>Does this provide a particular advantage over starting as root and then<br>change to a non-root user/group while keeping the required capabilities?<br> Do you build with --with-capabilities?<br></blockquote><div> </div></span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Yes, the current use case we are looking to support is one where starter itself is</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">spawned by a non-root user, and we are looking to avoid using any kind of setuid</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">bit or file permissions on the starter executable, but rather stick to using runtime</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">capabilities only.</div><span class="gmail-im" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>> Add</span>s preprocessor directives which allow strongSwan to be configured to</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>>  1) start up as a non-root user<br><br></span>I guess we could also just remove that check.  However, an #ifdef is OK<br>too, but perhaps name it differently (e.g. STARTER_ALLOW_NON_ROOT),<br>because it's specific to starter and it doesn't "start" the daemon<br>non-root, it just allows starting starter non-root.<br></blockquote><div><br></div></span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">I agree.</div><span class="gmail-im" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>>  2) avoid modprobe()'ing IPsec kernel modules into the kernel, which<br>>     would normally require root or CAP_SYS_MODULE<br><br></span>This stuff is not required anyway, it's just a relict from the early<br>days of strongSwan.  Is it a problem, though, if modprobe is called?<br>(The exit status is not checked.)<br></blockquote><div><br></div></span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">From a system/debugging perspective its preferable to cut down on noisy failed</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">syscalls (e.g. avoid confusion when using Linux syscall auditing to diagnose an</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">issue), but I agree that a failed modprobe() call isn't harmful beyond this.</div><span class="gmail-im" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>> Additionally, some small mods to charon/libstrongswan ensure that charon<br>> supports starting as a non-root user.<br><br></span>Looks OK.  I've pushed the patch with some minor changes to the<br>starter-non-root branch.  Let me know if that works for you.<br></blockquote><div><br></div></span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Awesome! Thanks.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Should I submit another patch for the suggested revisions to the starter patch (e.g. #ifdef macro name change)?</div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 20, 2018 at 9:40 AM, Micah Morton <span dir="ltr"><<a href="mailto:mortonm@chromium.org" target="_blank">mortonm@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the patch.  I think this is mostly a legacy issue (i.e. when<br>
starting the daemon via starter).  charon and it's derivatives don't<br>
check whether they are running as root, so it's possible to start them<br>
as any user given the appropriate capabilities are e.g. set on the<br>
executable.<br></blockquote><div> </div></span><div>Thanks for the info, didn't realize starting via starter was the legacy way of doing it :) </div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> This patch allows for giving strongSwan only the runtime capabilities it<br>
> needs, rather than full root privileges.<br>
<br>
</span>Does this provide a particular advantage over starting as root and then<br>
change to a non-root user/group while keeping the required capabilities?<br>
 Do you build with --with-capabilities?<br></blockquote><div> </div></span><div>Yes, the current use case we are looking to support is one where starter itself is</div><div>spawned by a non-root user, and we are looking to avoid using any kind of setuid</div><div>bit or file permissions on the starter executable, but rather stick to using runtime</div><div>capabilities only.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Add</span>s preprocessor directives which allow strongSwan to be configured to</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
>  1) start up as a non-root user<br>
<br>
</span>I guess we could also just remove that check.  However, an #ifdef is OK<br>
too, but perhaps name it differently (e.g. STARTER_ALLOW_NON_ROOT),<br>
because it's specific to starter and it doesn't "start" the daemon<br>
non-root, it just allows starting starter non-root.<br></blockquote><div><br></div></span><div>I agree.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
>  2) avoid modprobe()'ing IPsec kernel modules into the kernel, which<br>
>     would normally require root or CAP_SYS_MODULE<br>
<br>
</span>This stuff is not required anyway, it's just a relict from the early<br>
days of strongSwan.  Is it a problem, though, if modprobe is called?<br>
(The exit status is not checked.)<br></blockquote><div><br></div></span><div>From a system/debugging perspective its preferable to cut down on noisy failed</div><div>syscalls (e.g. avoid confusion when using Linux syscall auditing to diagnose an</div><div>issue), but I agree that a failed modprobe() call isn't harmful beyond this.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Additionally, some small mods to charon/libstrongswan ensure that charon<br>
> supports starting as a non-root user.<br>
<br>
</span>Looks OK.  I've pushed the patch with some minor changes to the<br>
starter-non-root branch.  Let me know if that works for you.<br></blockquote><div><br></div></span><div>Awesome! Thanks.</div><div><br></div><div>Should I submit another patch for the suggested revisions to the starter patch (e.g. #ifdef macro name change)?</div></div><br></div></div>
</blockquote></div><br></div>