[Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

Schaufler, Casey casey.schaufler at intel.com
Thu Mar 13 01:52:34 GMT 2014


> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of ???
> Sent: Wednesday, March 12, 2014 6:06 PM
> To: 하이츨러; dev at lists.tizen.org
> 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 : bj.im at samsung.com
> 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 : c.haitzler at samsung.com
> 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
> Dev at lists.tizen.org
> 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
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list