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

Carsten Haitzler c.haitzler at samsung.com
Thu Mar 13 02:55:18 GMT 2014


On 03/13/2014 10:52 AM, Schaufler, Casey wrote:
>> -----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.

launcher - you can't trust that. it runs as the user. kernel has to
implement it at the exec() level.

> Or, set an access control list on the binary, with the names of
> the users allowed to use it.

that sounds more useful. :)

>>
>> ------- 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

-- 
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.



More information about the Dev mailing list