[Dev] Access control design for user applications
casey.schaufler at intel.com
Tue Apr 15 22:27:25 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Rafal Krypa
> Sent: Tuesday, April 15, 2014 9:33 AM
> To: dev at lists.tizen.org
> Subject: [Dev] Access control design for user applications
> I'd like to start a wider discussion on the topic of access control for
> applications. This wasn't properly discussed on this list yet and is raising
> concerns in the thread about Cynara. I believe that the core idea described
> here is now "officially blessed", and should be put in the Wiki. If I'm not
> proven otherwise, I will edit the articles myself.
> *Definition of application*
> It is mainly about applications installable by users (e.g. from a "market"), but
> could be extended to some preinstalled applications as well. Both web
> applications and native programs are considered.
In particular, an "application" is anything installed by the application installer.
> *Area of access control*
> Access to sensitive user resources is being controlled (i.e. stored data, device
> nodes). By granting several privileges to the application, user gives access to
> a subset of these resources. Access should be enforced to this subset.
> Granularity of this access control is based on application privileges, as defined
> here: https://www.tizen.org/privilege Any access between different
> applications should also be restricted.
This is but basically sound. It does not address /dev/camera, but describes
the general idea.
> *Support for multiple-users*
> Access restriction between device users is out of scope of this policy.
> However multiple users must be properly supported.
I'm not sure what the difference between "device users" and
"multiple users" is as you've described this.
> *Smack policy for applications*
> Each application will be run with a separate label, belonging to the User
> domain. Label will be based on package id and allocated during installation.
> Suggested template for application label is "User::Application::$PKG_ID".
May I suggest "User::App::$PKG_ID" instead? There are consequences
if the label is more than 23 characters. Nothing to worry about if we stay
on box, but serious once we go off the box using IP.
> Each application label will be given the same set of Smack rules, based on a
> template. These rules should allow applications to contact with services for
> accessing sensitive resources, but prevent direct access to these resources.
> Services will run with either "System" or "User" label, so applications will be
> given write permission to these labels. No rules between different
> applications will be permitted.
That's required for proper isolation.
> One option for applications to share data will be public app directory,
> accessible RW for all apps. This will be achieved by labeling such directories
> with "User::Application::Public" and giving full transmuting access to all aps
> for that label.
I would be happier with "User::App::Common".
> *Why separate Smack labels*
> Application sandboxing with Smack gives two important things. First,
> application cannot steal data from another application. It will be prevented
> from taking other app's files, sending signals or tracing. Second, it provides
> reliable application authentication via SO_PEERSEC. Services can identify
> applications in a way that cannot be spoofed.
> *Policy for accessing sensitive resources* Access control based on application
> privileges will be enforced in user space by services. Services shall query
> Cynara policy service for policy decisions.
> *What will prevent applications from bypassing services* Original idea from
> Casey is to not give applications read access for "User" and "System" labels.
> This shall prevent opening of any files with such label, even in O_WRONLY
> mode, because open would fail while reading inode. Unfortunately actual
> Smack behavior doesn't meet that expectation and allows open with
> O_WRONLY if only write access is granted. Casey wants to change that with a
> patch, which we are still waiting for.
In test now.
> Another alternative solution would be to use different label for services and
> different one for the resources themselves, allowing applications to only
> write to the services.
The label of a domain's private data should be the domain label.
> There are some additional ideas and proposed extensions to the above
> model, but I'd like to write about them separately.
OK. Thank you.
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev