> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa > Sent: Tuesday, April 15, 2014 9:33 AM > To: [email protected] > 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. Yes. > *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. Yes. > *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 > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
