[Dev] [Multiuser] System User ID Policy for the Daemon Processes
l.stelmach at samsung.com
Mon Apr 7 11:30:19 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.
Samsung R&D Institute Poland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: not available
More information about the Dev