Security of PolicyKit

[David Zeuthen]

Hi,

Sorry for not replying until now - I've been traveling.

On Sat, Jan 1, 2011 at 12:16 PM, memolus at googlemail.com
<memolus at googlemail.com> wrote:
> As far as I know:
>
> * The authentication agent (e.g. PolicyKit-gnome) allows to enter a
> password without being spoofed, provided that you've somehow verified
> that it's the real dialog (a secure attention key, e.g. Ctrl+Alt+Del,
> is not implemented). In contrast it's not able to prevent mouse click
> emulation. The reason this is not possible yet is that it depends on
> some work in the graphics stack being done. Therefore there's are no
> passwordless buttons.

That is more or less correct. In fact, with the way PolicyKit is
designed, the authentication agent can easily run on a *separate*
device. For example a usb-attached device with a small display / big
OK button. Or an app on your cell phone. Or whereever.

> * If an graphical application has a certain non-one-shot permission,
> any malware can control the GUI, until you "drop" the permission.

I don't like using the word malware. But, yes, if

 a) a process in your desktop session, let's call it FileManager, is
    granted a temporary authorization for modify-device (suppose you
    authenticated to do that); and
 b) FileManager uses mechanism, let's call it DiskDaemon, to do stuff; and
 c) DiskDaemon allows processes with the authorization modify-device
    to do something privileged;

then, sure, if you control the FileManager process then you can do the
action represented by modify-device.

> * Because policykit does not not run in a separate security context,
> malware could hijack the authentication dialog and spoof the text in
> the dialog - thus tricking the user into install things that are not
> desired.

Yes, in the current distros / authentication agents, if you have
malware running in your desktop session it can easily do that. So it
can trick the user into e.g. installing software from the distro via
e.g. the PackageKit mechanism.

FWIW, I'd be more concerned about the malware zipping up ~/.firefox
and sending that somewhere.

> The long-term is:
>
> * Authentication agent in a separate security context
> * A secure attention key for non-consumer setups
> * Yes/no dialogs are possible, but not explicitly planned
> * You will have a look at further ideas, if you've got the separate
> security context and all that "jazz"
>
> Is that right?
>
> Is there any process on the graphic stack, the X server and SeLinux?

There's no concrete effort going on that I'm aware of (but a lot of
the pieces are almost there now, see below).

The way I'd like to see this happen is by having a "secure desktop
session" that goes along with every head/monitor (e.g. separate X
server and so on). So if there's a polkit authentication request the
user would see a dialog asking for the Secure Attention Key and upon
pressing the SAK the secure desktop session would be shown / capture
input (systems without SAK would just show it immediately). Much like
fast-user-switching works today.

Btw, the "secure desktop session" would host more than just polkit
authentication dialogs - it would also be used for the "unlock screen"
dialog and also used for other password dialogs (e.g. gio/gvfs dialogs
asking you for smb/nfs passwords).

We'd then have a "system compositor" to manage all your normal desktop
session and the "secure desktop session" - including 3d transitions
(think rotating cube, fades) between them. FWIW, I've talked at length
with both Jon (gnome-screensaver/gdm) and Kristian (wayland, X.org,
DRI etc.) about this setup (and I think we all agree something like
this could be nice) but AFAIK no-one is working on it - it's all
blue-sky right now!

(Also, FWIW, I don't think it's really priority to work on this
(albeit it would be nice) - it's much more important to secure things
like ~/.firefox.)

Hope this helps.

     David

PS : you do not need SELinux (or similar) for any of this - it is
sufficient to just run the "secure desktop session" as a separate uid
(much like gdm runs as the 'gdm' user) - maybe even spawn a uid on
demand. I don't know.