On 03/13/2014 09:12 AM, Bumjin Im wrote:
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.haitz...@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.
user_2 and user_3 should be able to happily install the app... just
user_2 and 3 are barred from senging sms's. if user_2 and user_3 just
have access to the dialler or messaging subsystem they can do the same
thing without installing anything - send sms's to premium sms numbers
and cause a bill. this has nothing to do with app execution or
installation permissions, but permission to access a service that can
CAUSE someone to have to pay a bill. pretend user_3 just kept sending
sms's to their friend... while roaming... and every sms costs $1. they
send 500+ a day because user_2 is a teenager who loves to chat with
friends all day and has no idea of the cost they are incurring. same
scenario.
security here should be done at the service access level (access to
sending an sms, or sending to known premium numbers) and non-authorized
usres are simply denied. if every user installs their own apps in their
own dirs - they are in charge. they can install or remove their own
apps. no other user apps can be touched. system installled apps (in
/opt/ as opposed to $HOME) are controlled by the "admin" (owner) user.
any credentials for billing per apps should be stored in $HOME - per
user. billing like for calls and sms that is done for the account holder
as a whole, should be allowed to be restricted by the owner (person
being billed). :)
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?
apps installed AS the usr id... belong to THAT user id. you don't need a
shared app location with mixed user id's (right now it's all root except
indeed data... and /opt/home/app .. these are owned by app... which just
smells wrong to me). if apps are installed in $HOME/apps/ (or somewhere
else in $HOME) and are owned by the user... unlike now where the
binaries are owned by root, then you don't have the possibility of a
setuid root binary in a pkg. binaries are installed by the user in the
user dir with user permissions. user can delete them. like any files
they own. no special permission needed.
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?
yeah. just saying that a group per app really isn't even needed if users
install their own apps. if its personal - no other users have acces. if
its system installed, other users do. credentials for logins, accounts,
billing are private per user except for billable services like
sms/calls/data usage on 2g/3g/lte etc. and these should all have access
policies settable by the "owner" and enforced by system daemons.
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..
hmm - if we expose this by usb block access... then you can easily screw
with permissions/ownership from the pc end. for mtp - i am not sure if
mtp can guarantee ownership correctness, but i guess it can't because a
pc can lie to it even if it supported ownership tracking, thus you
expose data that should not be to users not owning it, or allow a pc to
change/mess with permissions or ownership that it shouldn't be able to.
i smell problems here in making this have any ownership at all if it is
exposed externally without any form of real authentication.
the only way this could/would work imho is if it were exposed by
something like sshfs which requires me to authenticate with a username +
password and/or public key auth. then at least there is some level of
guaranatee that the user is "me" as they posess my private ssh key. if
this is the case, then we don't need any special filesystem at all. we
can expose any amount of the fs we like in any way - how it is
physically mounted, partitioned and mapped is not relevant. we can even
use a single big partition and thus expose as much of the storage as
possible, minus what is used by the os+user data. i'd highly suggest not
doing any kind of ownership/security on any filesystems we expose to
other devices without significant authentication mechanisms like above.
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???
as above in #1 and in my comment in #5 - primary user can deny
configuration access to other users, OR allow it (based on groups). they
can allow or deny data plan usage, mms, phone call etc. etc. usage on a
user-by-user (or group by group) basis. in this case you likely want
iptables/chains rules that can deny certain network routes to certain
user/group id's, if the primary user wants to use both wifi and data
plan, but guest users only allowed wifi. :) again - owner (admin) user
sets up such permissions. when you create new users we can create them
by default with the most restricted set of permissions (or offer a user
profile on creation - untrusted guest, trusted friend or fellow owner,
with each profile giving more and more access and the owner able to
fine-tune these if/when needed).
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.
if owner == developer, then a developer user should be able to setuid to
the owner at a minimum. in fact imho developer login should probably run
as the currently "logged in" user by default, BUT imho by default the
user should get an on-screen prompt to "allow dev shell" (maybe with pin
# - or probably lock screen is good enough as this would hide the
ability to say "ok" to dev shell). then when a developer develops...
they, get their dev shell logged in AS their user... by default (the
prompt can have a checkbox to "never ask me again" if this is annoying).
advantages to this is:
1. you find a developers phone. it's locked, you can plug it into your
pc... but can never get a dev shell wihtout unlocking the screen and
saying "ok", so dev shell access will be denied unless you know the
screen unlock (good).
2. the obvious thing happens - you switch user, new dev shell logins run
as that new user. if user is locked - then same as #1. you have to
switch to the other user and/or log out that user to get the dev shell
for YOUR user (switching requires you unlock your other screen too - so
same story).
this allows you to buy 1 device and share between N users - each with
their own login. their login when on the screen is tied to their dev
shell - same user. if you can't access the display, you can't access the
user remotely via dev shell.
in the end there has to be root access in a simple way. maybe install a
su package or something (so it's not there by default, but able to be
added if you have dev access and you agree to add it). if you don't do
this, people will just find exploits instead. take the ps3 as a golden
example. it was uncracked, until sony removed the "other os option". no
one wanted to bother hacking it or care, because there was a legitimate
way of doing what you want. the moment this was removed, it was
compromised. sony gave the hackers a REASON to try find exploits. don't
give them a reason. if i, as the onwer of MY phone, want root access, i
should get it. end of story. if i have other users or not, it's my
phone, and their data and usage of my phone is under my rules, so i
should have access. if they don't want that - they should go buy their
own. :) this is a standard social norm. you come to my house, you are
under my rules.
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.
... prepare for a rant ... :/
sued by who? you provide a way for a customer to have full control of
the product they bought. who will sue? show me a legal precedent of
this. where is it? EVERY windows pc sold gives the owner ROOT
(administrator) access - in the dos days there wasn't even such a
concept... it was a free for all. there has never been a single law suit
i have ever heard about that has succeeded in punishing a pc maker for
shipping windows with administrator access allowed for the user. same
for redhat. they ship redhat enterprise with root acesss allowed. ubuntu
- same. apple (osx) ... same. i can continue. decades and billions of
pc's shipped world-wide and not a single case that i know of. i don't
buy the "sue" argument. i don't buy the liability argument. history says
otherwise.
the attitude of "we know better than you, and you shall be denied access
to your own os core, even though it's open source and we like to bandy
about the words 'open source' with tizen to suck you in, you shall never
be allowed the right to fix/repair or modify it, even if it was build
directly from open source" is a poor one. this is not an open os. not by
a long shot. saying tizen is open source and then doing this kind of
lock down goes fundammentally against everything the linux foundation
stands for. everything the open source community and developers who
built the software you use to make tizen stand for. this is a great way
to make sure you do NOT make friends or get users or a following. in the
end people will see just how closed tizen is and say the same things
about tizen they do about android - it's all a CLAIM of being open but
when it comes down to it, it's locked down and held tightly under
control. we all come off as hypocrites. people have asked on tizen
mailing lists and at conferences many times "what is different/batter
about tizen?". theyare asking for a reson to leave their os and
ecosystem behind. if we are just as locked down, then you are pretty
much losing all the reasons. there is minimal point in publishing yoour
source if you can't USE it to fix things, improve things or alter the os
as you see fit. that is the POINT of open source. to allow for that.
imagine you were the developer of... let's say eglibc. you know there is
a bug, or you just optimized something and you'd like to try it out.
tizen uses eglibc. but i, the develoepr who wrote the code tizen depends
on, even if i buy a tizen device am denied the ability to upgrade/fix my
OWN software *I* wrote. why? because i'm "too stupid" to deal with it?
because of security? (seriously - it's my device. my phone - the only
one i compromise is ME .. and if i give other users access to my device
i am compromising - then that's my choice). it's insulting to treat
people that way. especiallly those that you depend on to provide the
base for your os. it's a great way to be a hypocrit and ensure there is
no reason for peolpe to use/move to and develop for tizen. you offer
nothing new and unique vs your competitors.
sorry. i have to rant about this, but this is a key and core topic that
needs discussion. if tizen wants to be locked down, then claim that,
don't put big banners about being open on it. be honest at least. at
least i'll know then to avoid it and never bother owning a tizen device,
as even i, as a core developer, am denied access to my own woftware i
wrote (access to modify it, improve it etc.) on tizen devices. and i
guarantee you, i will not be the only one with that view. i have been
around the block a few times, and you'll find 1000's of developers with
the same view. easily.
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.
generally speaking, if the data is not "human
browsable/digestible/editable", it's put in dot files to hide it. this
is the case of db's... unless we have db browser/display tools where i
can see the tables and content and mess with them... :) so we should do
the same... :) appfw - hear this! :)
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@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@lists.tizen.org
https://lists.tizen.org/listinfo/dev
