[Dev] [Multiuser] System User ID Policy for the Daemon Processes
ds73.lee at samsung.com
Mon Apr 7 11:48:57 GMT 2014
>It was <2014-04-07 pon 13:19>, when 이동선 wrote:
>>It was <2014-04-07 pon 10:13>, when 이동선 wrote:
>> Hi, all.
>>> I am Dongsun Lee working in Tizen security part at Samsung.
>>> We are studing how to minimize the root processes in Tizen 3.0. To
>>> do that, one of what we need is the system user id policy to replace
>>> the root user.
>>>> So I proposed the policy, "one system user per domain"(refer to the
>>>> below mail). Even if only one man wrote the response mail, I think
>>>> people agreed with it. So I went further.
>>>> There is no daemon in some domains, so they don't need the system
>>>> user. And there may be more than two daemon in one domain. In that
>>>> case, one system user will be assigned for those daemons. (If other
>>>> system users are needed except the system users of domains, it
>>>> should be examined first by the security engineers before it is
>>>> Following is the example of the system user assignement.
>>>> [Domain] - [system user name]
>>> I am not sure if strict assumptions like one-uid-per-daemon or
>>> one-uid-per-domain are good starting points. My Linux experience
>>> tells me that we should take them with a grain of salt and be
>>> prepared to make decissions on case-by-case basis. The former policy
>>> may be too strict and require some code to be rewritten, possibly
>>> from scratch, which may be quite a lot of work. The latter, however
>>> seems too slack and not secure enough.
>> I admit that there will be exceptions to this policy, "one system user
>> per one domain". For those exceptions, we(the tizen security team)
>> can discuss with the developers case by case. I think this policy can
>> be applied flexibly enough to meet your view.
>Sounds reasonable to me.
>> I don't believe that every developer can add the system user to the
>> Tizen platform. I believe there should be an entity to manage the
>> system user assignment and it is the tizen security team.
>For starters review for changes to /etc/group and /etc/passwd seems like
>an appropriate procedure (platform/upstream/setup package).
>> And we are not planning to develop some codes to apply this policy.
>> We will just be monitoring the daemons and notify to the developers
>> when some security issues are found.
>> If we specify the user in the *.target or *.service file of the
>> systemd, the daemon will be started as a specified user. That's
>> all. We don't need any more code change.
>You may need to also add some capabilities because *some* services may
>require access to some system facilities that are accessible only to
>privileged processes (uid == 0 or proper set of capabilities). Then you
>may need to make sure the directory the process changes its root
>(chroot(2)) to (if it does) has its ownership set properly. And a dozen
>of other tiny details like these. That of course depends on what the
>service is supposed to do.
You are right.
To minimize the root processes, we are preparing the following
- system user id policy
- how to collect information about the capabilities that daemons use
- how to apply the capabilities to the daemon instead of root user.
>Samsung R&D Institute Poland
More information about the Dev