Re: [gdm-list] Password-less login, last take

[Milan Bouchet-Valat <nalimilan club fr>]

Le samedi 27 juin 2009 à 18:12 -0400, Ray Strode a écrit :
> Hi,
> 
> On Sat, Jun 27, 2009 at 3:07 PM, Milan Bouchet-Valat<nalimilan club fr> wrote:
> > I'd like to wake up the old story of password-less logins, and hopefully
> > fix it quickly, since all the required parts are here now. I've created
> > a patch for the gnome-system-tools that will add the user to a specific
> > group if the option "Don't check for password on login" is ticked.
> So thinking about it, we already have:
> 
> 1) Automatic login
> 2) Timed login
> 3) passwd -d
> 
> I'm not really a fan of adding yet another way to do this.  If none of
> these are really sufficient, then I'd rather make one of them
> sufficient (maybe make TimedLoginDelay=-1 mean "never start
> timer"?)...
> 
> You mention passwd -d being a security hole in the bug report, but I
> don't see what security ramifications it has over your proposed
> solution.
> 
> If you do passwd -d then obviously ssh won't let you login with a
> password anymore.  That *increases* security, since it forces you to
> use public keys.
Sorry, I was not expecting to replay the whole debate around that. But
here's the rationale for that feature (much wanted, Windows and Mac OS
already have for a long time).

Automatic and timed login are GDM convenience features that are really
useful when you are the only person to use the computer, or the one that
uses it the most (laptops are in this case). But the case I want to
handle is about a computer used by several people, just like a home
desktop computer is. You can't log a user directly there, and yet users
don't want to type in their passwords because the physical environment
is secure.

Then you might think of the 'passwd -d' way of solving this. First,
there is no convenient (read: graphical) way of doing this currently, so
that's not really used at all. And that's not secure nor practical
because:
- any guy reaching your computer can actually perform any admin task
just like installing software or messing with your system (which friends
at home often do in your back ;-) )
- any guy reaching your computer can also change your password so that
you're locked out of your account
- you cannot use ssh since you have no password

My proposal (on which we kind of agreed with both GDM and g-s-t
maintainers back when I suggested it) solves these problems, and is more
practical and more secure at the same time. I admit that creates yet
another design, but that's not a big deal: just a group membership.
Maybe we can integrate this feature with autologin so that the autologin
account is also allowed password-less login - that would be more
consistent.


> > Now we only need to GDM to ship with default PAM configuration file
> > that use that feature so that distributors can easily enable it.
> > Unfortunately, these files are customized most of the time, so they will
> > have to adapt their versions before that works. (The 'nopasslogin' group
> > will have to be created by downstream before the feature is enabled,
> > anyway.) But modifying the default file is still useful, at least for
> > reference.
> Maybe it would make sense to provide a hint on how to accomplish this
> in the gdm documentation instead of in the reference pam file?
These are the parts I'd like to discuss. The documentation should
mention it for clarity's sake. I don't see why the default PAM file
should not use it, maybe in a commented line if you think that's a
security issue. Anyway, distributors seems to ship their own files, so
that's mostly about giving them hints.

> I guess g-s-t could modify the pam file itself, too...
They could, but my approach is that the feature is disabled unless the
distribution creates the group 'nopasswdlogin', so that we don't mess
with distribution's security policies. And modifying a PAM configuration
file from a script looks quite complex and risky, at least from my
unexperienced POV. Since distributions ship their own PAM files for GDM,
I think we can tell them to enable this feature by adapting these files
and creating the required group in a script, both in the GDM package.

Can we agree on this kind of solution?


Cheers