[Dev] Access control design for user applications

Rafał Krypa r.krypa at samsung.com
Tue Apr 15 17:04:10 GMT 2014


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.
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. 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.

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.


More information about the Dev mailing list