Re: Questions about PAM, GDM and gnome-screensaver

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]