Security of PolicyKit

[memolus at googlemail.com]

2011/1/17 David Zeuthen <zeuthen at gmail.com>:
> Sorry for not replying until now - I've been traveling.
You did not even reply on my last e-mail from 9th December 2009.

>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.
or an button on your screen, but only in theory.


>> * 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.
Regardless of the possibility to control a process, what is about
moving the mouse pointer?


>> * 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.
Or e.g. gain root access. If you open a policykit dialog after malware
was installed in your session, it can get root access if you use your
password.

> FWIW, I'd be more concerned about the malware zipping up ~/.firefox
> and sending that somewhere.
Than what? Preventing root access seems to be an requirement to
prevent software to send your private data to someone else.

>> 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.
Why do you need a SAK for switching to the secure desktop session?
Will there be any password? A step further I would like to have the
secure desktop session seamless integrated into the normal desktop
session.

> 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).
or your firefox password manager

> 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!
rotating cube? If you think of sudo, which runs in the normal desktop
session, it seems to be a step backwards. But who knows, maybe it's
necessary.

> (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.)
like everything in my home directory. But if you've got a good working
security concept, both aspects will be solved together, I think.

> 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.
Or seperate uid for every process? This seems to be a workaround.