Weekly Edition
Return to the Press page
| |||||||||||||
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica)
ars technica reports from the Ubuntu Developer Summit. "PolicyKit integration is also another topic that is considered highly relevant for Hardy Heron. PolicyKit is a new framework for secure privilege elevation. When programs currently need to perform operations that require permissions higher than those of a regular user, privileges for the entire program must be elevatedtypically with a graphical sudo utility. PolicyKit will instead require developers to isolate functionality that requires higher privileges in individual non-graphical utilities and services that will be accessed by programs through a D-Bus interface."
(Log in to post comments)
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 10:08 UTC (Fri) by irini (guest, #48834) [Link] Hi, I don't understand much of this article but I think it deals with securing the system. I'm not a developer and for some time have been using Linux on a regular basis but only yesterday it occurred to me that maybe I ought to do something to make my system more secure - the question is can it be done without having to use a terminal? Or maybe I shouldn't worry? Because actually everything seems to be working fine.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 12:01 UTC (Fri) by hummassa (subscriber, #307) [Link] This is for developers only. Think about this: When I want to install a font (globally) I have to write to directories that are protected by the system, so Ubuntu asks me for my password before elevating my priviledges so I can do that. The plan is to have a daemon running automagically that will write to those directories (running already with the necessary permissions) and communicating to said daemon via d-bus, so you don't have to give your password every time and maybe making not a lot of commands sudo-able like they are now. That would be a change that the developer of Control Panel / Appearance / Font Installer would have to implement, not you. You would not see the command line (as you shouldn't be seen it today, anyway)
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 13:14 UTC (Fri) by job (guest, #670) [Link] What a waste to have those daemons running constantly when they are very seldom needed. Only allowing certain privileged operations for non-privileged users is what you normally use sudo for. Since Ubuntu is already using sudo in the base install, it would be interesting to know why they chose not to go with that for this functionality as well.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 13:40 UTC (Fri) by michaeljt (subscriber, #39183) [Link] Just a thought, without knowing the details: in theory such daemons could be started on demand.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 15:50 UTC (Fri) by walters (subscriber, #7396) [Link] That's why D-Bus System Activation was created.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 2, 2007 14:54 UTC (Fri) by nix (subscriber, #2304) [Link]
You can't use sudo to say e.g. `only system admins may modify this gconf
key'. If a (future) gconfd talking over dbus used policy-kit, the local
administrator could specify things like that.
Think of policy-kit as being sort of like a finegrained sudo for d-bus:
unlike sudo it's used by *applications* so that they can ask `can I do
{blah} on behalf of user {foo}?' where {blah} may well not be `execute
this binary'. sudo isn't really a good fit for that.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 4, 2007 23:26 UTC (Sun) by job (guest, #670) [Link] That's because gconf is broken by design. If you want that kind of fine grained permissions from your system, you have to store each key in a separate file. This is how Linux itself handles for example the sysfs directory. Another design option is to use a configuration server. There is such a concept already within X11, but GNOME chose for very dim reasons not to use it (to be fair it would have to be enhanced to support that kind of security). Still not a good reason to go the simple and transparent way with sudo, which would be much easier and more obvious how to automate anyway.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 5, 2007 11:36 UTC (Mon) by nix (subscriber, #2304) [Link] Er, policy-kit is useful for things *other* than gconf, you know (in fact I'm not sure if gconfd can even use it yet). It can also mediate things other than file access, which the Unix permission system has little hope of. e.g. one of the existing keys controls who is allowed to power the machine off *and at what times it may be powered off and on*. Do *that* with permissions. (Yes, PAM can do it: guess what, that involves special-case code that's only useful for mediating that one operation.)
Daemons waiting for commands hardly consume any resources at all Posted Nov 2, 2007 22:41 UTC (Fri) by hummassa (subscriber, #307) [Link] 0% CPU some RAM, that can be swapped out an is only swapped in if the commands arrive.
Daemons waiting for commands hardly consume any resources at all Posted Nov 4, 2007 23:58 UTC (Sun) by job (guest, #670) [Link] But lack of RAM is why a five year old average laptop is slow today (because of swapping), and the CPU is just not a bottleneck for most applications.
Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) Posted Nov 3, 2007 19:38 UTC (Sat) by drag (subscriber, #31333) [Link] Sudo is evil, btw. Well.. I don't like the idea of having all these message passing things and daemons and such that are in charge of providing privilaged access to various end users it's still much better then combining X and sudo. X is complicated thing with many many different libraries and applications and such. When using gksudo or something like that to give privilaged rights to a GUI application your essentially trusting that the entire stack is safe and uncrackable since sudo is going to usually give full root rights to whatever application your using. This (using sudo) is not so problematic on a single user or home desktop were the user's files and data stored in the /home directory is the single most important thing on that computer (in otherwords it's fairly pointless for a attacker (either human or virus) to care about gaining anything other then user-level access) but on multiuser systems like a LTSP or corporate environment were computer control is needed then it's a very bad idea. DBus and associated daemons controlling various privilaged things is not good, but it would be a big improvement over what Ubuntu and friends are using right now. I figure minimize the danger it's probably a good idea to write these daemons to be as minimal as possible with specific purposes, standardized libraries for sanitizing dbus input and be written in a high-level language like python for easy auditability.
|
|||||||||||||