
On 27.05.2012 19:05, Claudio Freire wrote:
On Sat, May 26, 2012 at 3:09 PM, Guido Berhoerster<gber@opensuse.org> wrote:
Every admin would have their own user account, and that account would be a member of the group that has admin rights over the resource. That's how it has always been done in cli land, AFAIK, and that's how it ought to be done in the GUI too.
No, it isn't how it's done today with policykit nor is that how it should be done for the complex and fine-grained access control policy that is required here. We need roles as groups are much too limited and unsuitable for numerous reasons. The most important are that they are too coarse, difficult and inefficient to administer and inherently less secure. Roles allow fine-grained and centralized assignment of permissions to operations (rather than just filesystem objects) and improve security since they need to be explicitly assumed, possibly requiring authentication.
But what stops policykit from using group information?
I was not referring to filesystem-based permissions, I was talking about policykit checking group membership, as groups *are* roles.
policykit indeed blurs the line as it allows to use groups to assign users to permissions and thus allows groups to be used as roles. But you were talking about "how it has always been done in cli land" and if we want a unified solution (e.g why should a certain user be granted permission to shut down the computer from his desktop but not from a local console using /sbin/shutdown?) which includes tools without explicit policykit support, permissions on filesystem objects as well as fine-grained permissions to operations (that can be controlled with SELinux or AppArmor) groups are unsuitable for the above reasons.
But I'm intrigued by your assertion that groups are inherently less secure. Why? What would you propose to use instead? (links would be fine)
Simply principle of least privilege, if your permissions are based on groups you have all privileges permanently, a role in RBAC implementations such as SELinux or Solaris needs to be explicitly assumed for an operation requiring special privileges. Obviously this doesn't apply to policykit. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org