Re: [GNUnet-developers] packaging GNUnet for OpenWrt

[Daniel Golle]

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