2011/1/17 David Zeuthen <zeut...@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. _______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
