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] > *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. > > 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 examplefor such limitation. For another case, I can't imagine how a privilege like "http://tizen.org/privilege/filesystem.write"; could be safely implemented with only Smack and DACfor access control.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
