gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] packaging GNUnet for OpenWrt


From: Christian Grothoff
Subject: Re: [GNUnet-developers] packaging GNUnet for OpenWrt
Date: Tue, 02 Jun 2015 20:25:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]