Re: [GNUnet-developers] packaging GNUnet for OpenWrt

[Daniel Golle]

Hi Christian,


On Sun, May 31, 2015 at 05:27:21PM +0200, Christian Grothoff wrote:
> On 05/31/2015 04:51 PM, Daniel Golle wrote:
> > By now the main difficulty I got is that I'd want a way to start
> > gnunet-arm in foreground, so it can be monitored by procd (or other
> > init system) and most important: it would also allow to kill and
> > restart stuff reliably. See
> > https://gnunet.org/bugs/view.php?id=3804
> 
> Oh, but then just start 'gnunet-service-arm' directly.  gnunet-arm -s
> just starts gnunet-service-arm in the background, so if you want it in
> the foreground, it is totally fine to just directly run the service (you
> can still use gnunet-arm -e to stop it).

Ok, did that. Thanks for the hint!

> > Another issue is that most services started by gnunet-arm should be
> > run as uid:gid set to gnunet:gnunet or gnunet:gnunetdns. Some will
> > require root proviledges at least at some point (e.g. gnunet-vpn, see
> > below).
> 
> 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, ...)
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.
I also believe that any good piece of software should be able to adapt
to the presence of either or both security paradigms.
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.
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...


> > 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).



Cheers


Daniel