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. 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. 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. I hope we don’t have many cases where a system file (e.g. /dev/camera) provides multiple resources requiring disjoint privileges. If this is not a general problem we don’t need a general solution. The question we need a quick answer to is “how many cases do we have”? So the idea for solving the problem with DAC must rely on groups and adding application process to appropriate groups by launcher. ACLs can help if we need to give access to camera for more than one group. For example, if there is an existing setup that already relies on group DAC access, it would be possible to add one more group for managing privileges and not break existing setup. But I don' know if it's the case and ACLs add more complexity (and possibly overhead).
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
