Darren: > The GUI shouldn't be running as the user though. The input and output > is through the GUI and that means it has to be trusted and is in fact > part of the Trusted Path. That doesn't mean it needs to run with > privileges(5) but it shouldn't be running as the user.
Thanks for reminding me of this. For those of you who took the time to read the discussion on the GNOME screensaver-list, you'll notice that this came up. http://mail.gnome.org/archives/screensaver-list/2008-January/msg00003.html At the risk of encouraging more Linux-bashing, reading this thread you will notice that the Linux community seems to think that the Xserver supporting something called XACE (X Access Control Extension) and labelled objects will address these issues. I'm not sure if they are considering a11y, nor am I sure if XACE will be supported on Solaris. It might be helpful if Alan has any information about whether XACE might be a part of a solution here. I think the PolicyKit aspects of the discussion may be unrelated. PolicyKit was brought up because it (like the lock screen program) pops up a dialog asking for the root password, so they have a similar problem to solve. Since the lock screen program requires a backend daemon running as root which actually talks to PAM, and since this root daemon should have access to the Xauth keys for each display, it shouldn't be hard to make lockscreen work like this: 1) The user runs lockscreen, which runs any eye candy background as the user 2) When the user hits a key or moves the mouse, a message is sent to the daemon telling it to pop up the dialog. Since the daemon is running as root, and should have access to the Xauth key for each display, it should be possible to launch the dialog as another user (say the "gdm" user which is designed for UI's that accept passwords), and also run with the Security Extension to prevent Xauth snooping. It's a bad idea, in general, to run GUI's as root, so I think using a user like the "gdm" user makes more sense. 3) When the user enters the password, the GUI dialog sends the password to the daemon for actual PAM authentication. If this succeeds, a message is sent to the eye candy userland program to tell it to stop locking the screen. One idea that I have tossed around a few times, though not in this forum would be for the GDM daemon to be this background daemon. Since GDM already knows about PAM, audit, etc. it might be nicer to have just one daemon running than two. I realize PAM, audit is done a bit differently for login versus lockscreen, but I'd think it should be possible for GDM to be smart enough to handle either case. This does raise some issues for a11y. As a quick aside, it isn't strictly necessary for a program to use GTK+ to be accessible. Java is also accessible. You could also write a dialog using a widget-set that doesn't support ATK (such as Motif or X11), but hack the dialog to generate appropriate ATK events as the user interacts with the GUI. Though this last option could be a lot of work, even if you only implement ATK for the small set of widgets that a lock screen dialog would require. Most existing a11y programs (such as orca and GOK) depend on the ability to snoop on dialogs to report what is going on in other ways (text-to-speech), and to allow users to control the GUI via alternative input programs such as GOK (on-screen keyboard). If we make the password entry dialog inaccessible to snooping, then we also make it inaccessible to AT programs. However, as has been pointed out before, the UI for entering your password is not really that complicated, so a reasonable solution to provide a11y might be as follows: 1) Embed an onscreen keyboard directly into the dialog, much like gnome-screensaver already supports: http://bugzilla.gnome.org/attachment.cgi?id=69696&action=view 2) Instead of providing magnification, it might be sufficient to just provide a hotkey that increases/decreases font size in the dialog. And the ability for the user to configure the default font size. 3) Some ability to launch text-to-speech, mMuch the same as GDM currently allows you to hit a hotkey to turn this on. Or we could allow the user to configure that this is on by default. Or we could try to detect if the user is running orca, and assume they want to run it in the dialog as well. 4) Some ability for the dialog to detect and honor whatever theme is being used by the user, so if they are using a high or low contrast theme, this isn't lost when they go to the lock screen dialog. Perhaps the userland eyecandy program could communicate the theme to the background daemon. Using approaches like the above, it should be able to provide a11y support in a lock screen dialog. ----- As a separate topic, does Trusted Path apply to other programs that require password entry, such as Thunderbird, Evolution, etc.? If so, perhaps the same model could work for these programs. Using Thunderbird as an example, perhaps we could design things so it could likewise ask GDM to provide the password entry dialog so that username, password entry could be handled by a non-snoopable dialog running as the GDM user with the Security extension. I am not sure if you could do something like an IMAP/POPT connection in a PAM module. If so perhaps such a PAM module could pass back to Thunderbird whatever is necessary for it to actually talk to the server without Thunderbird ever being aware of the password. Or perhaps the dialog could be written to pass the username/password back to the application in a private fashion (perhaps via a socket), so at least the password isn't snoopable via Xauth, even if it is snoopable in the userland process (which you might be able to protect via other ways - by turning off dtrace and other programs which can snoop a process running as the same user). ---- Just some thoughts... Brian
