| |||||||||||||
|
| |||||||||||||
Fedora 12 to remove unprivileged package installationFedora 12 to remove unprivileged package installationPosted Nov 20, 2009 19:45 UTC (Fri) by dskoll (subscriber, #1630)In reply to: Fedora 12 to remove unprivileged package installation by drag Parent article: Fedora 12 to remove unprivileged package installation
The use case is "Being able to perform daily desktop activities without granting access to the root account". That's all.
sudo grants restricted access to the root account. So does Policy Kit. The technical details differ (sudo does it in-process with a SUID binary; Policy Kit does it via IPC to a daemon running as root), but you're just quibbling over semantics by claiming that Policy Kit does not grant "access to the root account." Note that I have no strong preferences for sudo over Policy Kit except for the general observation that very granular and tweakable security facilities are often harder to get right than less granular ones. However, as long as distros do a good job of providing sensible Policy Kit defaults, then Policy Kit is fine. The big issue was that F12's (now reverted) policy was not very sensible.
(Log in to post comments)
Fedora 12 to remove unprivileged package installation Posted Nov 20, 2009 21:18 UTC (Fri) by drag (subscriber, #31333) [Link] Yeah. The defaults were not that sensible. Only one user should be administrator and it should of been apparent in the release documentation.However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80. So ya any security issues in dbus itself or the dbus libraries that applications use would quite easily lead to a compromise and that is something that distros and developers are going to have to be very careful about. As long as that is audited and user supplied input over dbus is carefully managed then it should reduce the attack vector for attackers seeking local root exploits by quite a bit for typical desktop users (vs traditional linux desktop were open sudo and su access are regularly used features)
Policy Kit vs sudo Posted Nov 20, 2009 22:07 UTC (Fri) by dskoll (subscriber, #1630) [Link] However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80. Except there are two huge differences:
So it's not the case that all the security lies in dbus. The security lies in dbus and the policy kit daemon and in making sure your policies are correctly implemented. It's the last two (especially the last one) that will cause trouble. I'm not convinced that a root-privileged daemon that sanitizes its input is any more or less secure than a SUID binary that sanitizes its environment, etc. It seems to me neither approach is inherently more or less secure.
|
|
||||||||||||