Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

> On Fri, 2008-01-04 at 19:16 -0800, Ted Gould wrote:
> > If the solution uses PolicyKit could Sun provide their own
> > Authentication Agent that implements this the same way as today?  It
> > would seem that the same requirements would be in place for other
> > PolicyKit authentications.
>
> The PolicyKit authentication dialog suffers from exactly the same
> problems. There's some suggestions (that I need to reply to, sorry for
> the lag Martin) in
>
>  https://bugs.freedesktop.org/show_bug.cgi?id=13742
>
> but I'm pretty sure this won't be solved properly before XACE and
> labeled objects in the X server (which requires something akin to
> SELinux; whether AppArmor on Linux works, maybe, I haven't checked. On
> Solaris I believe RBAC, capabilities or similar is used) is available. 
>
> In the interim one course of action is to move all authentication
> dialogs (including those asking for e.g. credentials to connect to a
> remote share etc. - e.g. the yet-to-be-written GtkMountOperation dialog
> for gvfs would use it too) to the login screen using SAK (just like
> Windows does). So the user interaction would be something like
>
>  +----------------------------------------------------------------+
>  | You need to authenticate because of XYZ. Press Ctrl+Alt+Delete |
>  | to proceed.                                                    |
>  +----------------------------------------------------------------+

Wouldn't using the Security extension also be a solution that could
be used to better secure the PolicyKit authentication dialog?

> and then we essentially fast-user-switch to the gdm screen (a sandbox
> environment) to do the authentication. Of course with this approach you
> have issues with the accessibility stack; not so much bringing it up
> (need to do that for accessible login anyway) but to make sure it uses
> the same settings as the logged in user. 

The problem with fast-user-switching is that it only works in
environments that support VT.  It wouldn't work, for example, in an
XDMCP remote session, or other sessions that aren't associated
directly with the console.

That said, I don't think it is strictly necessary (from a Section 508
perspective) to inherit the user's a11y sessions.  This is really a
nice-to-have feature.  As long as it is easy for the user to switch
the dialog to whatever a11y mode is needed, then Section 508
requirements would be met.

In our discussion so far, people have seen that there is some value
in GDM managing lock screen.  I think the main value in this idea
is that security issues, PAM, etc. is complicated and hard to get
right.  Therefore it might make sense to have a single daemon
responsible for displaying a dialog for getting username/password
entry in a secure fashion rather than trying to implement this logic
right in multiple programs.

This dialog could perhaps use the X Security extension for added
security and provide accessibility by having on-screen keyboard, theme
switching, and magnification managed by hotkey.  Perhaps this dialog
could run as a different user to protect from ptrace style snooping.
If there could be some handshaking so this dialog could inherit the
user's theme, that would be a great nice-to-have feature, but not
strictly necessary.

> Oh, and then there's the detail that f-u-s doesn't work properly on
> Linux with the current DRI/DRM stack [1]. So it's not really feasible to
> implement this either. 
>
> In conclusion. I don't think properly securing authentication dialogs
> are possible to do without teaching the X server about labeling it's
> objects; e.g. XACE (I'd loved to be proved wrong though). The good
> things, however, is that people are indeed working on XACE; at least the
> SELinux bits of it.

You don't think the X Security extension by itself is a possible
solution?  I don't understand.  Perhaps you could explain why a bit
more?

Brian