[LEDE-DEV] running stuff as !root

John Crispin john at phrozen.org
Wed May 18 00:54:04 PDT 2016



On 18/05/2016 09:49, Etienne Champetier wrote:
> Hi,
> 
> 2016-05-18 9:25 GMT+02:00 John Crispin <john at phrozen.org>:
>>
>>
>> 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.
>>
>>         John
>>
> 
> Capabilities is the way to go.
> Filesystem capabilities are painfull, so we will use process
> capabilities (inherited from procd).
> 
> I've already integrated normal capabilities in ujail, so you can run
> as "reduced" root.
> 
> You can inherit capabilities between non root user (if you have
> capabilities to inherit...) but the program as to do it explicitly,
> so for exemple i could (not yet supported) launch zabbix with
> CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able
> to use it.
> 
> For subprocess to inherit capabilities without using root user, we
> need to look into ambient capabilities (linux 4.3)
> 
> Cheers
> Etienne
> 

Hi Etienne,

i agree, for now this should be handled via caps. never heard of ambient
ones, will look into that. thanks for the pointer.

	John



More information about the Lede-dev mailing list