> > 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 <[email protected]> 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)? > >
