Ubuntu Developer Summit lays out vision for strong Hardy Heron release (ars technica) [LWN.net]

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."

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] (9 responses)

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 (guest, #307) [Link] (8 responses)

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] (7 responses)

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 mjthayer (guest, #39183) [Link] (1 responses)

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] (2 responses)

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] (1 responses)

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 (guest, #307) [Link] (1 responses)

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 (guest, #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.