On 06/02/2015 02:56 PM, Daniel Golle wrote: >> gnunet-service-arm should be started as user 'gnunet:gnunet'. Those >> parts that require root should be installed SUID (like the helpers), >> and gnunet-service-dns should be SGID (and group 'gnunetdns'). > > The problem here is that not all systems allow bottom-up delegation of > priviledges (think: SUID/SGID executables, su, sudo, ...), but rather > rely in a top-down apporach (think: change from being root to less > priviledged users, or further limiting priviledges by other means such > as chroot jails, namespaces, cgroups, capabilities, applying seccomp > filters, ...)
Well, except for the binaries expecting to be installed SUID, the existing GNUnet programs don't "drop" privs. Naturally, it is always fine to put them into a variety of jails, and if you don't use ARM but use some other kind of system service that might be able to do the service-specific jailing, that might be the way to go if SUID is unavailable. > I know this is an old argument with various reasons for both sides to > do things as they do. I doubt there will ever be final answer on > how to do this properly. Oh, but I think it is clear: ideally both -- jails, plus starting with minimal permissions (plus sub-processes gaining some if really required). > I also believe that any good piece of software should be able to adapt > to the presence of either or both security paradigms. As I said, you can do service-specific jailing, and we do have an open bug report for the creation of AppArmor profiles for the various GNUnet services. > Thus, it'd be great to start gnunet-arm as root and have it starting > child processes with limited priviledges instead of starting gnunet-arm > as user 'gnunet' and have it rely on sudo, su, SUID/GUID for child > processes needing more things user/group 'gnunet' can't do. Ah, but the SUID ones are helpers, so children of services that are not even started directly via ARM. So if you can't have SUID, your only somewhat-sane option is to run the service as root so it can run the helpers as root, and then use capabilities to restrict the services that do run as root. > However, this could also be carried out by procd instead of gnunet-arm > if I sit down and write all the init scripts for each and every GNUnet > service... Yes, that maybe a reasonable option. >>> As that's a quite common problem for many network services, >>> OpenWrt recently started to implement seccomp to allow certain >>> processes to be run as root but only enjoy some-but-not-all >>> priviledges. >> >> Sure, but even that is too much for GNUnet. We can do with less, as long >> as the helpers can be SUID. > > seccomp filters can be implemented as a method for self-degradetion of > processes themself but also be applied externally, e.g. by the init > system (that's what procd's seccomp/jail implementation as well as > stuff like LXC does). > On the other hand, OpenWrt doesn't ship with any SUID/GUID binaries, > sudo or su by default and the use of these methods is kinda > discuraged (see above). Well, discouraging this is IMO a bad idea, there is a use for SUID/GUID, just like there is a use for capabilities. You'll only get the most secure system if you truly minimize permissions, and that means also sometimes the parent process having fewer permissions than the child process. My 2 cents Christian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
