[LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:46, Ferry Huberts wrote:
> 
> 
> 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.
> 
the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.