[Dev] processes running as root

Roman Kubiak r.kubiak at samsung.com
Wed Aug 20 10:33:36 GMT 2014


We did part of that work for the Mobile profile (when it was still 
alive), a summary of how we did that what tools we used etc. is on the 
Tizen wiki
https://wiki.tizen.org/wiki/Security:Analysing_security_privileges_of_tizen_services

we also tried dropping root for some important processes and got 
positive results using Linux Capabilities for example we got connman and 
wpa_supplicant running with non-root accounts, alarm-manager was one 
that worked too, security-server can run without root also.

best regards
On 08/20/2014 11:55 AM, Philippe Coval wrote:
> I think stephane said it all, but I'd be curious to know what will you
> expect from tizen or a dream secure system ...
>
> If root processes are critical problems please tell us.
>
> Then, It would make sense to identify those "root process"
> and then evaluate how to refractor them and/or reduce their
> capabilities to expectations ...
>
> Regards
>
>
> 2014-08-15 1:45 GMT+02:00 Stéphane Desneux
> <stephane.desneux at open.eurogiciel.org>:
>> Hi valentina,
>>
>> Yes we continue in that direction.
>>
>> The process is what Casey described: after some investigations, if we find
>> that we can adjust all the DAC & smack permissions to make a given daemon
>> run as something else than root (and without high privileges), we'll do it.
>>
>> But the most important is not to run as root or not: IMO, what is essential
>> is to give the exact level of privileges needed by a given service, not less
>> (of course, this wouldn't work) and not more (this would be a security gap).
>> I mean that running some daemon as a special user who has a lot of
>> privileges is not always the solution: having multiple 'roots' doesn't make
>> things simpler.
>>
>> The good question is perhaps: why this *specific* daemon needs so much
>> privileges ? Is it essential for the system ? Can't we make it run with less
>> privileges ? Could we split the daemon in two parts ? etc.
>>
>> Also remember that Tizen, as any other Linux distro, relies on upstream
>> projects. We can tweak things, but there are always design limits for that.
>> So, at one point, if another "more secure" (open or private) implementation
>> for a given service must take place, it's certainly possible: you'd just
>> have to compile the service with Tizen toolchain and write the corresponding
>> core API. The Tizen architecture, with its service layer, was probably
>> designed with that flexibility in mind...
>>
>>
>> Best regards,
>> --
>> Stéphane Desneux
>> Intel OTC - Vannes/FR
>> gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726
>>
>> Valentina Giusti wrote:
>>> On 08/12/2014 03:08 PM, Stéphane Desneux wrote:
>>>> Hi Valentina,
>>>
>>> Hi Stephane,
>>>
>>>> As Casey and Carsten said: things are not black and white... but simply
>>>> gray :) We *try* to reduce the daemons running as root as much as
>>>> possible. But it's not an absolute rule.
>>>>
>>>> Sometimes, it's possible to migrate a daemon from root to <some system
>>>> user> without much difficulties. A good example is weston in
>>>> Tizen:Common: it runs as a 'display' user, who has the proper rights on
>>>> the DRM and input devices.
>>>>
>>>> For some other daemons, it can become more tricky.
>>>>
>>>> If I take a quick look on a recent Tizen:Common snapshot, I can see that
>>>> there are some daemons running as root, as you noticed:
>>>>
>>>> root 159 1 0 03:22 ? 00:00:00 /usr/sbin/ofonod -n
>>>> root 161 1 0 03:22 ? 00:00:00 /usr/bin/alarm-server
>>>> root 168 1 0 03:22 ? 00:00:00 /usr/sbin/connmand -n
>>>> root 172 1 0 03:22 ? 00:00:00 /usr/bin/security-server
>>>> root 173 1 0 03:22 ? 00:00:00 /usr/bin/media-server
>>>> root 175 1 0 03:22 ? 00:00:00
>>>> /usr/bin/notification-service
>>>> root 239 1 0 03:22 ? 00:00:00 /lib/bluetooth/bluetoothd -E
>>>> root 344 1 0 03:22 ? 00:00:00 /usr/sbin/wpa_supplicant -u
>>>> root 1037 173 0 03:23 ? 00:00:00 media-thumbnail-server
>>>>
>>>> In this list, I see 3 categories:
>>>> - some daemons can very probably run as system users (media-server,
>>>> media-thumbnail-server, ofonod, alarm-server), if we're able to define
>>>> the appropriate rights
>>>> - for network and connectivity daemons (connmand, wpa_supplicant,
>>>> bluetoothd), it may be more tricky to migrate to non-root users, but
>>>> this needs some investigation
>>>> - some services need to run as root (security-server AFAIK)
>>>>
>>>> As Casey pointed, migrating from root to system users for some daemons
>>>> is an ongoing effort.
>>>
>>> thanks for your detailed answer. I was actually wondering how you
>>> proceeded with
>>> the identification of the processes that can be run as system processes
>>> and if
>>> you planned to continue in that direction for the services that still run
>>> as root.
>>> My guess is that this would help also with having a
>>> multi-user/multi-session
>>> system.
>>>
>>> Best Regards,
>>> - Valentina
>>>
>>>> Best regards,
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.tizen.org
>>> https://lists.tizen.org/listinfo/dev
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.tizen.org
>> https://lists.tizen.org/listinfo/dev
>
>

-- 
--------------
  Roman Kubiak
--------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140820/fdbce381/attachment.html>


More information about the Dev mailing list