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

[Milan Bouchet-Valat <nalimilan club fr>]

Le dimanche 28 juin 2009 à 11:31 -0400, Ray Strode a écrit :
> Hi,
> 
> > 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 ;-) )
> Not sure I follow.  Wouldn't installing software and other admin tasks
> require the root password?
Yeah, but most distributions don't use root passwords nowadays. You need to
enter your own password for PolicyKit to give you rights, or use sudo in
legacy cases. With 'passwd -d', you either forbid this completely, or allow
running admin tasks without any password at all.

> > - any guy reaching your computer can also change your password so that
> > you're locked out of your account
> Well any guy with access to your machine can change your password,
> true.  But that's true regardless.  Anyone with physical access can do
> anything they want.  Of course when you get access to your machine you
> can change it back...  Clearly passwordless login (via your way or
> passwd -d) should only be set up in environments where you trust the
> people who have access to your machine.
Sure, physical access makes any security mechanism pointless if the
attacker is willing to crack your machine. But that's speaking in
absolute terms. If we leave theory and go back to situations users are
faced with at home, people that have access to you computer are not
attackers and won't go to the BIOS to enter your system.

I can see many cases for this. Friends may just get things wrong when
you let them check their mail on your computer; your son could break
your system by playing with packages on the family's computer, while his
own account is not privileged. I've experienced a situation where a
friend of my grand parent's did break their network connection when
trying to make something work with Windows methods. Had him needed
password, my grand parents would have told them he shouldn't play with
that.

> > - you cannot use ssh since you have no password
> Sure you can.  You have to use a key instead of a password, but you
> should b e doing that *anyway*.
Unless you only allow SSH on your local network, where passwords are
easier to use and secure enough. That's what I'm doing now - but I agree
that's not a major usability issue.

> > 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 still don't see the practical problem with passwd -d.
> 
> > Maybe we can integrate this feature with autologin so that the autologin
> > account is also allowed password-less login - that would be more
> > consistent.
> Not sure what you mean, autologin already allows password-less login?
Yeah, but if you go back to GDM for some reason (need to switch to another
user, return to login prompt after suspend...), you need to type your password.
In that case, it makes sense to allow the autologin user to log in
without password too.

Another example: my dad uses autologin on his laptop, and when the
computer suspends, gnome-screensaver asks for his password; since he
forgets it all the time, he never suspends the machine. His case may
seem pathological, but it makes no sense to require a password in that
case while you can always access the account by rebooting the machine.
And I can swear you many users think in those terms too: "WTF do they
need my password, it's useless here!"

> >> 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.
> Given that most distributions use their own files here anyway, it might make
> sense to drop the files completely, or move them to the documentation as well...
No idea how they are used by Makefiles ATM. Let's simply add the line if
it's only for reference purposes, and you'll be able to do anything with
them later.

> >> 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?
> I don't really like this solution.  I don't like using groups like
> this.  The modern approach to user policy seems to be to assign
> capabilities with PolicyKit.
I certainly prefer PolicyKit over the old-fashioned Unix groups. But using
PolicyKit for this feature doesn't seem right either. We're not really dealing
with capabilities here. The main technical issue with using PolicyKit is that
gnome-system-tools don't use it, which would force us to wait for a new users
configuration tool to be created. And I've no idea of how PAM would allow for
authentication rules based on PolicyKit. Complex for no real gain, since we
don't need PolicyKit's flexibility here.

> Anyway, we're just talking about a hint for distributions to follow...
>  I don't care that much either way, but I don't know how Brian and Jon
> feel.
Jon did not seem to be interested in that discussion since he's been
drawn by the Shell's design... ;-) As I said, Brian was OK with my
implementation last time we talked about it, but that was a long time
ago.