| |||||||||||||
/etc/group/etc/groupPosted Nov 15, 2007 10:53 UTC (Thu) by rwmj (subscriber, #5474)Parent article: Centralizing policy rules with PolicyKit
It's not clear what PolicyKit gives you over groups and setgid processes. You can add and remove users from the "managenetwork" group (or whatever you want to call it) and then they are or are not able to use the network management tools. Although there is no way to get someone to type their password in this scenario, I'm not sure how useful that is anyway - admins should tell their users to use password-protected screensavers if that's a real problem. Even with PolicyKit there's no way to stop a user from opening up the network manager (typing a password), then walking away. So to my mind this just looks like a reimplementation of groups. Sorry, of course I forgot: now with added XML (TM)!! Rich.
(Log in to post comments)
/etc/group Posted Nov 15, 2007 11:58 UTC (Thu) by james (subscriber, #1325) [Link] With extra flexibility as to what they can do with those management tools. It's not all or nothing any more.
/etc/group Posted Nov 15, 2007 12:54 UTC (Thu) by TRS-80 (subscriber, #1804) [Link] The primary advantage of PolicyKit is that it allows conditions like "only the console user can change the networking", and being able to deal with fast user switching through integration with gdm, which pam_console is unable to do. This is better than groups and setgid processes, because it means someone can't log in over ssh and mess with another user at the console.
/etc/group Posted Nov 15, 2007 14:25 UTC (Thu) by drag (subscriber, #31333) [Link] It seems to me that Polykit is a way to reduce exposure of privilaged applications to non-privilaged users. This should go a long way to reducing the amount of root-level exploits going on in a typical Linux desktop. Say you have (a classic example) cdrecord (or wodim or whatever people use nowadays) set to run with root rights for a paticular group of users. Well that's a non-trivial program and it's going to be ripe for abuse if a account gets comprimised. Essentially your giving people rights to at least part of the in-kernel SCSI stuff. Another example is the Ubuntu desktop were you have a large number of applications that require gksudo to work properly. Your giving root rights to many large and complex GUI programs with a whole host of dependancies and many many different code paths that little to nothing to do with.. say.. updating the machine with latest security fixes, which is a required thing to do and not easy for admins to do for users travelling around with laptops. So PolicyKit, it seems to me, will reduce the exposure of these privilaged activities down to the dbus system and the input of whatever daemon you have floating around to take care of the request. I figure that as long as you have strong input validation and dbus was designed correctly then it should be a much better system for Linux desktop rather then the sudo/setgid stuff.
|
|||||||||||||