The access control list idea covers exec() as well. Having both a launcher and allowing direct (exec) invocation begs for problems like this. The ACL solution makes the most sense in the light of both mechanisms being allowed.
From: 임범진 [mailto:[email protected]] Sent: Wednesday, March 12, 2014 7:00 PM To: Schaufler, Casey; 임범진; 하이츨러; [email protected] Subject: Re: RE: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment Launcher can perform those idea, but do you think we can ignore exec()? -- May the Force be with you ---------------------------------------------------- * BumJin Im * Senior Engineer, Mobile S/W Platform lab, S/W Platform Team Samsung Electronics --------------------------------------------------------------------------------- ------- Original Message ------- Sender : Schaufler, Casey<[email protected]<mailto:[email protected]>> Date : 2014-03-13 10:52 (GMT+09:00) Title : RE: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]] On > Behalf Of ??? > Sent: Wednesday, March 12, 2014 6:06 PM > To: 하이츨러; [email protected]<mailto:[email protected]> > Subject: Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User > Environment > > 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. Add an extended attribute (security.TIZEN-WRT-ALLOWED-USERS) to the binary. The launcher can look at that attribute to determine if the current user is allowed to launch that application. The data in the attribute can be a list of UIDs or user names. If the value is "*" everyone gets to use it. If the attribute is missing, no one does. The launcher can be configured to ignore the attribute on systems that only support a single user. The application installer sets the attribute based on whether it was purchased for just that user or for everyone on the box, or for a limited set. Or, set an access control list on the binary, with the names of the users allowed to use it. > > > ------- Original Message ------- > Sender : [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected]<mailto:[email protected]> > https://lists.tizen.org/listinfo/dev [cid:[email protected]] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=6ec7a20cfdabd4ef782b243169ad2b665eba74a5ea819d2adc75e351fd20fb7b72bcb903983aba63d8c023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0]
<<inline: image001.gif>>
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
