Brian Cameron wrote: > 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: > > Will the daemon running as root have access to all the xauth keys?
I'm working from memory, but back when I managed a system using NIS+ and therefor SecureRPC's for NFS, and the user's homedirs were mounted with the -secure option, root couldn't read any of thier files unless they were world readable. Won't that be a problem for this daemon too? -Kyle > 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 > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org >
