[Dev] Access control design for user applications

Rafał Krypa r.krypa at samsung.com
Fri Apr 18 09:40:01 GMT 2014


On 2014-04-17 20:40, Schaufler, Casey wrote:
> OK.
>
>  
>
> Smack provides the application based control. If the application does not have the privilege it can never access /dev/camera.
>
> We define away the privilege differentiation issue by asserting that /dev/camera always provides exactly one resource, and that said resource always requires privilege. That is, you can’t access /dev/camera if you don’t have the privilege.
>
>  
>
> We have a problem when there are two applications AngryTwitterBirds and PoliteYelpPigs that both have camera privilege. Fred has both installed, wants AngryTwitterBirds to have access to the camera but does not want PoliteYelpPigs to have access to the camera. Wilma also uses them, but wants both
> to access the camera. What matters is not just the user, it’s the user’s decision to restrict their own access based on application level privilege.
>

Yes.

>  
>
> This means that we can’t use the UID to control access to /dev/camera. Bugger. We can use the group, as you’ve advocated all along. Let’s try to keep this whole thing as simple as possible then. How about we add a group for each “privilege”. The launcher can ask Cynara if the application, when run
> by this user, should have the privilege. If it should, it adds that group to the list the application runs with.
>

This is exactly what I tried to propose in the 2nd, DAC solution. Perhaps I haven't stated it clearly enough. Therefore I'm happy that you got the same idea.

> Access to /dev/camera is controlled by Smack (application needs access sometimes)
>

How about giving a single Smack label to all such resources (e.g. System::Privilege::Direct)? All applications would get access to that label, but they would still need DAC permissions to use that. By not using separate labels for each resource we could keep Smack rules for all applications exactly
the same.

> and by an ACL (HeeHee. You thought I’d give up on ACLs, didn’t you?) with an entry for the appropriate privilege groups.
>

I'm starting to suspect that you were a member of the POSIX.1e working group.

> There are some resources that can be accessed by more than one privilege. In the case of camera the ACL would look something like:
>
>  
>
> user::-,group::-,other::-,mask::rw,group:cameraprivilege:rw
>
> A device that requires one of two privileges might have:
>
>               user::-,group::-,other::-,mask::rw,group:fish:rw,group:chips:rw
>
>  
>
> Unfortunately, any case where the file provides multiple resources will require a group that represents both privileges:
>
>  
>
>               user::-,group::-,other::-,mask::rw,group:fishandchips:rw
>
>  
>
> You could of course optimize the single privilege case to set the GID on the device file.
>

I hope that I can start with optimization for single privilege case and just set group owner. Later if there is a need for multiple privileges to grant access to a single device, ACLs can be added to allow more than one GID.

> I can’t say I like it much, but it would allow the Smack label and ACL to be set by udev configuration and not changed thereafter. The group set is known at build time, so there’s no need to add groups dynamically. The launcher then has to add a group to the application process for each allowed
> privilege, but it doesn’t have to care if they will be used for anything.
>

Like you say, everything will be statically defined at build time. Only list of groups for application processes will be dynamic, based on Cynara policy.
To support this, I have to implement mapping of privileges to GIDs and proper logic for the launcher. This seems like a good next step.


More information about the Dev mailing list