Forgot to mentioning about #3. The purpose of gid per app was to provide access control for "user" to limit/allow executing apps. I thought we can give gid which are mapped to each app to corresponding user to allow executing apps that allowed to run. If we have better idea, it'll be very happy to hear.
------- Original Message ------- Sender : [email protected] Date : 2014-03-13 09:12 (GMT+09:00) Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment As I mentioned before, I haved focused on usage scenario. Technically most of the things are just matter of policy configuration, but wanted to remove complexity as much as possible. Answer inline. ------- Original Message ------- Sender : [email protected] Date : 2014-03-12 19:26 (GMT+09:00) Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment 1. i would disagree with "only default user is able to install & uninstall applications". it sounds like an artificial limitation to work around our installation of apps in system dirs. i would say "only default user can install/uninstall *SYSTEM* apps unless they grant access to other users to do this too" (eg use some group and place other users in the same group that allows this - default user is in that group by default). system apps are available to all users. user installed apps are only available to that user. user installed apps of the same name override system installed apps when executing an app. [Bumjin] This is because of complexity reduction. Let's say a usage scenario. Assuming that there are 3 users in a device, user_1(owner, who pays the bill), user_2 & user_3 (not bad guys, able to install apps but could be selfish) user_1 installed a "hot_porn" app for $20, and did not allow to run the apps to any users. The "hot_porn" app can send prem can send premium SMSs to get in-app-purchase contents. user_2 does not know the existence of "hot_porn" app, and he tries to install it again. However user_3 does the same thing and user_1 gets trippled pay bill next month. Another scenario... user_2 installs "hot_porn", and downloaded many hot contents. user_3 didn't like it and remove it. Who gonna pay user_2's lost money? We ended up with the simplest setup for this becuase money has involved a lot. 2. the above impacts "all files and dirs owned by root" for apps. this also nicely avoids worrying about setuid root binaries in apps... their files are never owned by root... so who cares? :) [Bumjin] Even in Tizen 2.2, all(most?) files are owned by root except for /opt/home/app/ and /opt/[appid]/data. What do you want to point out? 3. why is there a group id per app? what purpose does this have? it sounds like a needless complication (and surely is not sensible if apps are installed as a user). is this for defining per user access to system apps? 4. device media storage ... shouldn't this just be spread across /home so all users already use it? we can use quotas if we want to limit usage per user. [Bumjin] Device media storage is a partition that exposed to user by USB connection to PC and heavily using NTP for data transfer. The device must guarantee some amount of free disk space to satisfy user. We see enoumous complains from many media that why disk space is smaller than the advertizement based on this device media storage free space. If this things fulfiled, your idea is not bad for me. But I don't know the technology in this field.. 5. configuration of device i think should be allowed to other users... based on what the default user decides - eg add user X ro group "wifi" and thus they can configure wifi (but not bluetooth, unless added to the "bluetooth" group). we don't have to IMPLEMENT the support for adding other users to such groups to start with, but allow for it in future and ensure we implement the appropriate security checks in daemons that configure these things. [Bumjin] This is also money involved therefore very sensitive. user_1(owner, $$) spent all the data plan and he doesn't want to pay more, so he shut down data network and only to use Wi-Fi. user_2(able to setup network), wants to use the device as Wi-Fi hot spot, and change the Wi-Fi setting to use data plan and forward to his "other" devices. Who gonna pay the bill??? 6. developer support should be assignable to any set of users. imagine i have a small company. i buy 10 phones for my developers to use, but they share them. they each have users/logins on these phones, each with their own config/data/setup, but they all are developers doing development and they have 10 DIFFERENT phones to test different models and features of hardware and swap.share them around as needed to save money. same for "developing application can be launched only as default user and developer user". :) [Bumjin] This is strongly not recommended by any of our customers. This is a basic requirement to avoid any "setuid" environment to go other users. Since we give "shell" to the developer, if we give "setuid" property, then the developer can explore other user's data and try to manipulate. So, I wanted to limit the developer as a "owner". But, I also think we can make some other approach on this. Please fire up any better idea. 7. shell prompt for developer should only support developer user... no. we NEED to be able to change user id. we need to be able to switch smack labels. app is being used as developer, you now suddenly have a bug. it's using 100% cpu and you don't know why. normally i'd "ssh in", sudo or su - to the user logged in and then strace -p PID. if there is no way to "become" the uid of the given problem app we are in trouble and can't figure out what's going on. same for gdb attaching to that problem process etc. provide a way to do this - it may be sudo + password (set up when developer mode is set up) or some special setuid root tool that does this auth + switch, but it's something we need and developers will demand. [Bumjin] Same as above. setuid is never allowed by any of our customers. Even suided device will never pass through to the production process. We'll be *sued* if we provide such functionality. Your concern should be taken care of by other method. 8. /home/username/dbspace ... please NO! /home/username/.dbspace if anything ... hide it by default. and if anything... a db is just config - same thing. it should just be initted by the app or daemon or lib when/if neeeded. eg if it's email maybe /home/username/.config/email/ or for contacts /home/username/.config/contacts or if its a db for a "facebook app" .. /home/username/.config/facebook/ - inside these dirs they can do whatever they like. freedom to put sqlite db;'s or xml files or plain text or small furry animals. [Bumjin] This is just on idea. I think this is up to APPFW. 9. per system installed package ... peer user data (/opt/apps/[pkg_name]/data/[user_name])... sounds .. wrong to me. [Bumjin] Same as above. On 03/12/2014 10:04 AM, ??? wrote: 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. Bumjin _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
