[Dev] Access control design for user applications
r.krypa at samsung.com
Tue Apr 15 16:33:07 GMT 2014
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.
*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.
*Support for multiple-users*
Access restriction between device users is out of scope of this policy. However multiple users must be properly supported.
*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".
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.
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.
*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.
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.
There are some additional ideas and proposed extensions to the above model, but I'd like to write about them separately.
More information about the Dev