[LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 09:25, 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.
>


You might just as well switch on SELinux and use the policies that are 
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is 
negligible.


> 	John
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>

-- 
Ferry Huberts