[Dev] Access control design for user applications

Schaufler, Casey casey.schaufler at intel.com
Fri Apr 18 17:42:51 GMT 2014

> -----Original Message-----
> From: Rafał Krypa [mailto:r.krypa at samsung.com]
> Sent: Friday, April 18, 2014 2:40 AM
> To: Schaufler, Casey; dev at lists.tizen.org
> Subject: Re: [Dev] Access control design for user applications
> 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.

Yes, you were right all along. I was merely restating it to ensure I
had the whole story.
> > 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.

That would cause problems when we get to native applications.
You can't specify multiple groups with the setgid bit. Native applications
would be restricted to a single application privilege by the group
semantics. That, or we'd need a native application launcher.
We could start out with one label and make a project of breaking
it up when native applications become a real issue. I fear that OSP
may require that we do the separation now, but I'm willing to listen
to reason.

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

I was a founding member and was the technical editor when
we decided to withdraw the DRAFT. I was one of two people
involved with it start to finish. Just so you'll know, I find ACLs
(especially the directory defaults) painful and only suggest them
because this is exactly the purpose for with they are intended.

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

Yes, that seems prudent. I don't know of any directly supplied
resources that are allowed to multiple privileges. It would be handy
if that never actually came up. I'm not betting any large amounts
on that, however.

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

Yes, that seems like where we are. Onward! Make it so!

More information about the Dev mailing list