[LEDE-DEV] running stuff as !root

[Etienne Champetier]

Hi again,



2016-05-18 10:22 GMT+02:00 Ferry Huberts <mailings at hupie.com>:
>
>
> On 18/05/16 10:03, David Lang wrote:
>>
>> On Wed, 18 May 2016, John Crispin wrote:
>>
>>> 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
>
>
> SELinux's hit is for all intents and purposes zero as well nowadays.
>
>>> blown and hard to maintain. the idea would be to create a custom
>>> tailored solution for our requirements.
>>
>>
>> That is why I prefer AppArmor, you don't have the interaction between
>> different application configs that you do with SELinux, so you can focus
>> on the specific application that you are concerned about.
>
>
> AppArmor is significantly less secure than SELinux.
> And with SELinux you don't need all the preloading stuff that was talked
> about, you can just declare which ports are allowed.
>
>>
>> SELinux configs that Fedora uses have to be so permissive to keep from
>> breaking too many 'normal' use cases that I really question how valuable
>> they are.
>
>
> And this is based on what exactly?
> I've been using Fedora ever since SELinux was first enabled and I don't see
> that. Processes are well secured.
> If you think about stuff like Firefox, then ok, that one is really hard to
> secure, better run it in a sandbox.
> But process that are well-defined in behaviour are well secured.
>
>
>
>>
>> A SELinux system tuned by an expert is going to be more secure than an
>> AppArmor system tuned by an expert, SELinux just can do more (at least
>> right now). But there aren't many experts of that caliber around. A
>> reasonably competent sysadmin can understand an AppArmor config and
>> tweak it for their layout without too much effort (once they identify
>> that AppArmor is blocking what they are trying to do)
>>
>
>
> Agreed, it is a balance.
>
> However, I must note that I've encountered very few cases where the policy
> had to be tweaked, on my laptops, desktop and most of all servers.
>
> One example of tweaking is when I move a service to a different port.
> That is a single command, like (moving the port of the 'cockpit' service):
>>
>> semanage port -a -t websm_port_t -p tcp "$newport"
>
>
>
>
> My 2 cents :-)

Before talking about AppArmor vs SELinux, can someone take a look at
the userspace tooling size requirement ?
For exemple SELinux tools are mostly Python scripts

Etienne

>
>
>
>
>
>> David Lang