First of all, thank you for your active response. Many of the issues should be taken care of by AppFW engineers. I assumed many things because I don't know the Application's use cases. I'm now requesting AppFw enginners to dive in.
Your answers inline. Bumjin ------- Original Message ------- Sender : Jos? Bollo<[email protected]> Date : 2014-03-18 01:47 (GMT+09:00) Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment On mer, 2014-03-12 at 01:04 +0000, 임범진 wrote: > Hi all, Hi Bumjin, Hi all, > We have investigated what the security policy should look > like in the multi-user environment considering various > usage scenarios. I believe multi-user support is a > platform wide and full vertical task that everybody should > be involved, so please review the attached proposal and > it'll be happy to hear any feedback. With Dominig Ar Fool, we just finished to exam your proposal. First of all thank you for that proposal that clearly lists the purposes and is a solid foundation to progress. After review, we have a lot of remarks. page 2 ====== Terminology: We prefer to speak about the "main user" ------------ for the user that owns the device and to use the expression "default user" for the unidentified "guest" users. It should be at least one "main user" with the "admin" role, at least one admin: the main user. We disagree with the proposal "most files are owned by root". We want as few root files as possible. We prefer to give system UID to applications. That is the use with UNIX systems: think about users lp, mail, uucp, daemon, man, ntp, sshd, statd, named, dbus, polkit, ..... [Bumjin] I basically agree with this "system user" idea, but currently we don't have such user ID even though I mentioned a little bit of such user ID in the document. I think we need to discuss more on this. We disagree with "only default user is able to install & uninstall applications". We prefer to define roles, basically 3 roles: admin, normal, guest. The users with the role of "admin" can add/remove any applications (both user-level applications and system-level applications), (s)he can choose the visibility (all user, some user, non-guest ...). Normal users can install user-level applications for him(her) self only. Guest users can't install or remove application. [Bumjin] Everything is matter of policy. If we limit to "default user", then we can easily extend. The original purpose was to simplify the use cases but I think we can make it configurable and let OEM completes the policy. page 3 ====== Home directory is created when a new user is added, its Smack access label is set to "User" and its smack transmute flag to TRUE. [Bumjin] This will need more discussions. We need to keep the home directory as the user's data storage and at the same time, we need to provide data sandboxing per user. page 4 ====== See above for user roles (admin/user) It is merely a good idea to use 600 as default mask but it is too simple for sharing cases then it must not be strictly enforced. [Bumjin] This is just a default mask, I didn't mean to enforce it, we cannot enforce it anyway. I personally don't know any use case for data sharing between same app from differen users, so I don't have better idea on this. We will need massive discussion on this. We disagree (see above) with "all files and directories are owned by root". We disagree with "system assign group id per application" and prefer to not make wide use of groups. (typing 'id' currently shows too many groups). [Bumjin] Just wanted to provide some way to enforce execution of an app per user. Casey has some ideas, so we will get better idea soon. page 5 ====== We are okay to launch service not user oriented with their application uid (not a special uid). The user oriented service MUST be launched with the user UID (and also its environment... What may be difficult). page 6 ====== See above (page 3) for putting smack data to user's home directory. User specific data must be created within its home directory by applications and libraries. The best place to use are $HOME/.config/... and $HOME/share/... By principle, daemon should not have specific user data. For the small account of daemons that should have user data (media manager, playlist, ...) we agree that it is the responsibility of the daemon to deal with user add and remove. [Bumjin] Agreed, my intention was to provide a way, not to enforce it. For external memory cards, we are thinking that the use of links in the home directories is needed for applying quotas (see below page 7). Mounting memory cards would imply the creation/synchronisation of the links and of the data on the card. For example: on the card, should exists the directories: - /home/user1...usern - /opt/... and the main FS would have the links: - /home/user1/sdcard -> /mount/sdcard/home/user1 - /opt/sdcard -> /mount/sdcard/opt That is our draft idea. [Bumjin] My point was that the SDcard cannot be access controlled when it's plugged off and plugged in to window machine. If we cannot fully enforce, then we should untrust. That was the simple reason. page 7 ====== Limiting user storage can be made with a quota like mechanism that implies that any user data must be within its home directory. page 8 ====== The users must be able to share their data with others using either DAC (groups or other) or ACL. Then we prefer to not write that file attributes are 600 or 700. [Bumjin] As above, I think we need to discuss in use case perspective before talking about security. page 9 ====== If no user has logged in, it is as if a guest is logged: not an admin. page 11 and 12 ============== We agree that both are out of scope. page 13 ======= The current and common usage is to set the home directory of root to /root not /home/root. We disagree with the use of user ids (names) in subdirectories of /opt. /home is the only place (and sdcards). See https://wiki.tizen.org/wiki/Multi-user_Platform_Metadata and https://wiki.tizen.org/wiki/Multi-user_Architecture for some hints. We disagree with any user specific process at application installation, user add or user remove. By principle, the data have to be created lazily. By principle, deleting the home directory of a user is enough to remove any user data. That point is really important because it improves widely the maintainability and the simplicity. page 14 ======= We agree only with alternative 2 because it doesn't have any {user} dir in /opt. We expect that the links: - /home/user/apps/pkgid/bin -> /opt/... - /home/user/apps/pkgid/res -> /opt/... are only for transitional purpose because it would be better for applications to access there data were they are. We prefer the directory /home/user/.config/appid/.... for application specific data, and the directory /home/user/share/appid for application shared data. Best regards Jos? Bollo > Bumjin > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
