[LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:

> On 18/05/2016 09:21, Radu Anghel wrote:
>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>
>> On Wed, May 18, 2016 at 8:29 AM, John Crispin <john at phrozen.org> wrote:
>>>
>>> ok, there had been some discussion about building a super daemon that
>>> runs, then ld-preloading bind() and co and using ubus to transport
>>> sockets around. using caps or /proc sounds like a good i between until
>>> such a daemon exists
>>>
>>
>> Most daemons I know of that need to bind to ports <1024 start as root
>> and after binding to the port they drop privileges to the privileges
>> of the user specified in their config file. For those daemons just
>> adding a user and specifying it in their config file should be enough.
>> For the daemons that don't need to bind to <1024 just starting them
>> from their own user account is ok as they don't need additional
>> privileges.
>>
>> For example the dnsmasq daemon has these options:
>>
>> # If you want dnsmasq to change uid and gid to something other
>> # than the default, edit the following lines.
>> #user=
>> #group=
>>
>> I don't think that integrating such functionality in ubus or some
>> other LEDE-only super-daemon is a good idea. Config options +
>> capabilities for those daemons withut such options is a good way of
>> doing this in my opinion. Also use different users for different
>> daemons, as others said.
>
> to elaborate, imagine dnsmasq running inside a jailm where ut only
> thinks it is root but is not in reality. also ld-preloading bind and
> connect would allow us to do pretty adavnced stuff like only allowing
> dnsmasq to open certain ports. essentially an acl around the
> bind/connect calls.

well, between the different namespace options (pid, user, network, filesystem) 
you can have the thing running in the container thinking that it is root and the 
container configuration limit what it can do. This is the bleeding edge of 
containerization, so advanced use cases like you are defining are going to be 
fragile as the kinks get worked out. But there are a lot of people working in 
this problem space right now.

I personally think that the best bet is to ignore the problem for now, but keep 
an eye on the different container projects, try to make them all work on LEDE, 
and as the dust starts to settle, pick the top (or top few) survivors and start 
using them.

Right now some of the namespace types open up as many vulnerabilities as they 
allow you to close.



Another think to keep in mind is that most of these projects allow you to 
package up and containerize individual daemons, but as soon as you start needing 
to have the different things interact with each other (say the container running 
LUCI needs to start configuring the container running asterisk), they get really 
ugly.



And finally, many of the people focusing on these projects are aiming for the 
cloud datacenter market where every machine is ephemeral and is expected to 
disappear and take all data/configs stored on it as it goes. So they all rely on 
some external storage/database setup to hold all that stuff. Not something 
normally available to LEDE type devices running in homes and small offices.


David Lang