>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 >>>> assigned.) >>>> >>>> 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.
>Kind regards, >-- >Łukasz Stelmach >Samsung R&D Institute Poland >Samsung Electronics > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
