> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa > Sent: Tuesday, April 15, 2014 10:04 AM > To: [email protected] > Subject: Re: [Dev] Access control design for user applications > > On 2014-04-15 18:33, Rafał Krypa wrote: > > There are some additional ideas and proposed extensions to the above > model, but I'd like to write about them separately. > > *Direct access to sensitive resources* > In some products it may be necessary to allow selected applications to > directly access a sensitive resource. One common example in Samsung is > camera device, which should be accessed with nearly zero delay. Such access > doesn't fit in the desired access control model. Such cases should be limited > in > number, but probably cannot be eliminated. I can think of two different ways > to accomplish that: > > 1. Additional Smack label and rules, based on privileges > This is a blast from the past, a functionality that we had alot of in Tizen 2 > Smack policy. If the resource is well defined and can be labeled with unique > Smack label, like "System::Protected::Camera", only selected applications will > get a Smack rule to access it. The rule can be statically added > during installation, based on privileges requested by the application.Number > of such rules is expected to be small.
So far so good. > This solution has one big hole in it: doesn't support multiple users. If > application "FancyPhoto"is allowed to access camera for user1, it will > automatically allow user2 to useit as well. Users are not Smack entities. I like a DAC solution (below) better. > This can be solved with what José > Bollo proposed - using load-self Smack interface in launcher. Application > requesting camera access will get static Smack rule for the camera > label. During application launch launcher will check policy for current user > and > if user is not allowed to access camera with that app, the rule will be > disabled > for application process. > Going this way requires some changes to Smack implementation of load-self > interface. As José Bollo > found out, currently a process can set it's private rules back and forth, > removing any restrictions that were imposed by launcher. This is much too much work for the desired effect. > 2. Additional groups, based on privileges > The second idea is based on using DAC. For the camera example, the device > node would be accessible for selected group (i.e. "chgrp camera > /dev/video1; chmod 0660 /dev/video1"). During application launch, launcher > would check policy and add the application process to appropriate additional > groups. Set a POSIX ACL on /dev/camera. The installer can update the ACL if necessary. Groups also work, but you're cluttering up /etc/group. > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
