[packagekit] libpackagekit-gnome

[David Zeuthen]

On Mon, 2008-04-14 at 00:49 +0100, Richard Hughes wrote:
> >  InstallPackages (String package_names[])
> >  InstallGStreamerCodecs (String codecs[])
> >  InstallXineCodecs (String codecs[])
> >  InstallLinuxDeviceDriver (String modalias_list[])
> 
> That's basically what I wanted libpackagekit-gnome to look like - very
> high level.

Cool. Security concerns aside (see below), do you think it matters much
if it's a D-Bus service instead of a library? Just from a practical
point of view, my experience is that it's a lot easier to maintain a
D-Bus interface than it is to maintain a shared library.

> > Which is a lot higher-level and requires much less integration with each
> > application. And for bonus both gnome-packagekit and (some future)
> > kde-packagekit can provide that D-Bus interface. Meaning that users get
> > native looking KDE packagekit dialogs even when using Totem under KDE.
> 
> Hmm, valid point.
> 
> > The main bonus, from a security point of view, here is that we only have
> > to securely lock down the program providing this hypothetical D-Bus
> > service to avoid rogue software in the session to abuse e.g. an
> > authorization for .install that is valid for /usr/bin/totem (Totem would
> > be a lot of work to securely lock down, not to mention it would be
> > pointless).
> 
> Why would we have to lock down totem? - by lock down do you mean get an
> auth to install a file?

The basic premise is that someday we'll get a secure windowing system
and a secure UI toolkit [1]. So when we have that, we can write secure
UI applications much in the same way we currently write secure setuid
programs. 

A secure program, in a nutshell, means that you cannot tamper with the
code being executed when running /usr/bin/my-application. E.g. there's
no way to do LD_PRELOAD, no way to do LD_LIBRARY_PATH, you can't ptrace
it and no way to otherwise inject code. The docs for
polkit_sysdeps_get_exe_for_pid() discusses that concept in detail - see
[2] for the link.

Right now we don't have any facility for writing secure UI applications.
So if I'm a hostile piece of code then I can trivially use LD_PRELOAD to
inject code into /usr/bin/gpk-application. That code could make a call
into the PackageKit daemon and since we keep an authorization
for /usr/bin/gpk-application the PackageKit daemon would happily
install software on my behalf. So now the hostile code just elevated
itself to uid 0.

Before you panic keep in mind that this isn't that big of a deal because
of the state of X and UI toolkits in general. Most people have the point
of view that if you have hostile code running in your session it's game
over anyway since the only interesting bits are in $HOME. That and the
fact that the windowing system isn't really secure (see xspy.c for just
one example). 

(And if that's enough you can always just reconfigure the policy to
avoid allow authorizations to be retained; that way even hostile code
would get prompted for authentication.)

But _some_ day we will get a secure windowing system and a secure UI
toolkit. Presumably then we'll be able to make all the PackageKit UI
tools secure. So what does this mean? It means that authorizations
constrained to only work for these tools really are constrained to that.
So even if you had hostile code running in your session there's no way
it can inject code into the PackageKit UI tools and thus, there's no way
it can use the authorizations constrained to these tools.

Now, making a program secure is actually very hard. It means you cannot
trust any input at all. Specifically, for a program like Totem that use
a lot of video codecs you'd have to verify that the input (e.g. some
movie you downloaded off the Internet) doesn't cause buffer overflows
that injects hostile code. Which is flat out impossible in the real
world [3]. And even more importantly, it's not _necessary_ as totem
would already be locked down (via e.g. SELinux) if hostile code really
tried to do something out of the ordinary.

Now, suppose totem used libpackagekit-gnome to install a codec. That
means there's a PolicyKit authorization granting totem the right to
install packages via the PackageKit daemon. And there you have the
problem. Then people trying to exploit Totem would just include exploit
code that calls into the PackageKit daemon. Since there's an
authorization in place, it succeeds to install an rpm with some really
nasty %post stuff running as root. And then the exploit code owns your
box.

So.. that's the main reason that I think this needs to happen in a
separate session daemon. The interface exposed should be very very high
level.. mainly to avoid hostile code abusing this to install what they
want. That's partly why the suggested interface has methods such as
InstallGStreamerCodec(). In fact, it shouldn't provide a way to install
packages at all; only plug-ins. I think. Don't be tempted to just
provide a generic InstallPackage() method! Also, the session daemon
would _always_ ask the user for his consent even if there's already an
authorization in place.

Sure, all this is a bit academic but some day we _will_ have a secure
way of writing UI applications that can withstand even having hostile
code running in your session. And that day, we're going to have a
problem if e.g. Totem is authorized to install anything it wants.

Does this make sense?

Thanks,
David


[1] : and this is not too far away; XACE recently got merged into X.org
mainline. There's still a lot of work left though.

[2] :
http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-sysdeps.html#polkit-sysdeps-get-exe-for-pid

[3] : Totem is effectively loading millions of lines of code due to
it's dependencies... just look at all the bugs in image decoders.. and
then remember this is video decoders, e.g. one or more magnitudes more
complex