[Dev] Access control design for user applications

Schaufler, Casey casey.schaufler at intel.com
Tue Apr 15 22:11:22 GMT 2014

> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Rafal Krypa
> Sent: Tuesday, April 15, 2014 10:04 AM
> To: dev at lists.tizen.org
> 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
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list