wOn Thu, 2008-09-18 at 22:55 -0500, Brian Cameron wrote: > Stef: > > > Is there a standard way or goal for the UI and behavior of password > > prompts on the desktop? Besides having as few as possible, that is. > > There is Trusted Path to consider. To meet Trusted Path requirements, > any entry of the root password needs to be done via a trusted user. > This means that the dialog would need to run as a special trusted user, > and not as the user whose session is running. Much like the GDM GUI > programs are run by the special "gdm" user. Otherwise, someone who has > gained a user privilege could possibly snoop process memory space to > get the root password.
Someone who has gained a user privilege could possibly show a fake password input dialog that looks exactly like a "real" password prompt, thereby learning the root password. Same thing with VT swiching. It shouldn't be hard to make the it look like we are switching VT from a simple X11 program running as the user. If the local user account has been compromised it seems to me that all hope is lost. So I don't really see the point of all this Trusted Path complexity. But I'm no security expert; I might be missing something. > Also if the dialog is running as the user and > core dumps (or can be induced to core dump), then the password may be > left behind in the core file readable by the user. Also the dialog > would need to run with a separate Xauth connection to the Xserver to > protect against snooping via X interfaces. > > However, to resolve this problem would require a fairly significant > amount of infrastructure that does not exist today. Most people feel > that the existing security is "good enough", but sysadmins with strict > Trusted Path requirements would likely have to disable programs from > asking for root passwords in dialogs via programs like gnome-keyring, > PolicyKit, or gksu. > > gnome-screensaver has similar Trusted Path issues. I understand Jon > McCann is planning to fix this by making the screen lock program show > up in a separate Xserver running as a trusted user. This would work > via a mechanism similar to VT switching. Once that is done, perhaps > that could be extended so programs like gnome-keyring or gksu could use > a similar interface for added security and for meeting Trusted Path > requirements. That would also resolve a lot of the grabbing and > focus issues that plague programs asking for sensitive root passwords > in a user session. > > So this information is probably not useful in the short term, but > something to be aware of. A long-term goal should be to address these > issues so that root password entry is handled in a more secure fashion > in the future. > > Brian > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "The universe is always one step beyond logic" -- Frank Herbert _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list