Hi Christian, first of all, I'd be very glad if you or any of the GNUnet developers can review the way I split up GNUnet into several packages. The packages are now: gnunet : core components gnunet-conversation : conversation with pulse and gstreamer gnunet-experiments : currently only ATS, DHT experiments are not build gnunet-fs : filesharing stuff gnunet-gns : naming stuff gnunet-storage : storage backends gnunet-transport-bluetooth : depends on libbluez... gnunet-utils : gnunet-config and some other configuration tools gnunet-vpn : exit, pt, vpn
Please have a look at https://github.com/openwrt/packages/blob/master/net/gnunet/Makefile In order to break-out the transports from the core package, it'd be really nice to also split the config file snippets and have transport.conf, transport-http-client.conf, transport-http-server.conf, transport-bluetooth.conf and transport-wifi.conf. Similarly, the config snippets for each SQL backend could be in individual files to ease packaging. I can send the patches to the mailing list if you agree with that. On Tue, Jun 02, 2015 at 08:25:08PM +0200, Christian Grothoff wrote: > 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'll need to have a deeper look at ARM and see how this could work. > > 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). However, there are systems which follow a straight top-down approach afaik while exposing less or equal attack surface than systems using both. To make GNUnet work on systems following that parasigm, the problem are those sub-processes needing gain permissions using sudo, su or SUID/GUID meachanisms. On OpenWrt, busybox doesn't provide su and sudo. However there is a shadow-utils package which can provide them, but isn't part of the core packages. It's used mostly in places where packages didn't migrate their init scripts to procd yet... SUID/GUID isn't used anywhere afaik, so the way for now would be using shadow-sudo until a better way is found. > > 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. I'll have a look there, could be useful hints... > > 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. Another way might be to have those helpers started through ARM running as root and also have ARM run each child process with appropriate uid/gid set and priviledges dropped (in which way ever). > > 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. The problem with SUID/GUID starts with packaging SUID/GUID executables -- usually you'd use a post-install script to achieve that because you can't set suid/guid on the build filesystem because the build process doesn't have permission to do that... I'll try with shadow-sudo and I see how far I'll get... Cheers Daniel _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
