From: Rafał Krypa [mailto:[email protected]] Sent: Thursday, April 17, 2014 9:53 AM To: Schaufler, Casey; [email protected] Subject: Re: [Dev] Access control design for user applications
On 2014-04-17 18:09, Schaufler, Casey wrote: From: Rafał Krypa [mailto:[email protected]] Sent: Wednesday, April 16, 2014 3:22 AM To: [email protected]<mailto:[email protected]> Cc: Schaufler, Casey Subject: Re: [Dev] Access control design for user applications On 2014-04-16 00:11, Schaufler, Casey wrote: 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. Doing it with POSIX ACLs would still require cluttering /etc/group. It would have to be done on ACL group class, not user class. This is because the full triplet (user, app, permission) must be supported. Consider privacy setting application that can list and toggle application permissions for a user. If Smack grants access to /dev/camera for an app and ACL grants it for a user, the user will not be able to switch it in settings per application. Just like Smack doesn't know about users, user class ACLs won't know about apps. You are correct, ACLs don’t help. Alas, groups don’t either. Assume that /dev/camera “provides” exactly one “privileged” resource. It can only be used by applications with that privilege. We label /dev/camera “Privilege::Camera”. The installer and settings manager can adjust Smack rules based on the application manifest to allow or disallow application A access to “Privilege::Camera”. You could use either groups or ACLs instead of Smack if you prefer. So far I was considering only this, "easy" problem version. But it's not that easily solvable with Smack. What you described here is not going to work on a multi-user system. Consider the following example: - Your favorite application Angry Twitter Birds gets installed and it requests access to camera. Smack rule is created to allow "User:App:angry.twitter.bird" access to "Privilege::Camera". - User USR1 runs the application and it is able to access camera, everything fine for now. - User USR2 opens privilege manager application, founds that Angry Twitter Birds can access camera and disables it. If he runs the application, it should be prevented from accessing camera, but we cannot make it happen by changing Smack rules. - User USR3 is configured to not have access to camera at all. This also cannot be represented by Smack rules. To properly address the above cases I proposed two solutions: fine adjustment of per process Smack rules based on privileges or adding processes to additional groups. Both ideas require launcher to check if the application for current user can use some privilege (e.g. camera) and setup application process accordingly. You were right to suggest that DAC solution with groups is much simpler. 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. 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. Access to /dev/camera is controlled by Smack (application needs access sometimes) and by an ACL (HeeHee. You thought I’d give up on ACLs, didn’t you?) with an entry for the appropriate privilege groups. 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 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. Assume that /dev/camera “provides” two independent “privileged” resources, say “camera.still” and “camera.movie”. If application A is allowed to open /dev/camera because it has “camera.still” privilege there is no way to stop it from performing “camera.movie” operations. The only safe thing you can do is require that A have both privileges to open /dev/camera. The installer and settings manager will have to know that both privileges are required to allow access to the device. Once that is established, the access control mechanism, be it Smack or groups, is the same as the single privilege case. Either we have the easy case (one device, one privilege) or we have the impossible case (one device, multiple privileges). I hope it is clear why groups don’t help. Once you have access to the device you can perform any function it is capable of, regardless of why you were allowed to open it. I fully agree. The "hard" problem version, as you described, is impossible to solve with mechanisms we have. The obvious but expensive solution is to change the camera device driver to provide two interfaces, /dev/camera.still and /dev/camera.movie, each of which only provides the facilities appropriate to the privilege. That gives us the easy (one device, one privilege) case twice. Of course we can also ask for a service that would provide these privileges, so the problem would disappear. I'm afraid that there must be some limitations on implementation of privileges provided without a service. I agree that you described a very good example for such limitation. For another case, I can't imagine how a privilege like "http://tizen.org/privilege/filesystem.write";<http://tizen.org/privilege/filesystem.write> could be safely implemented with only Smack and DAC for access control.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
