gdm Create User

Douglas McClendon dmc.fedora at filteredperception.org
Sun Oct 7 20:22:12 UTC 2007


Steve Grubb wrote:
> On Sunday 07 October 2007 11:33:45 Lubomir Kundrak wrote:
>>> A successful account breach requires 3 things: a machine name, a valid
>>> account, and the password. Letting people know that an account is valid
>>> cuts the attack down to a dictionary attack.
>> So what about trying to hide the machine name?
> 
> Yes that is a good thing to try, but likely to be exposed. NAT's do some 
> degree of protecting this. But this is really not the point of this thread.
> 
>> This is plain nonsense. Time that was spent avoiding timing `attacks' was
>> wasted. The _password_  is meant to be a key that is to be hidden, not the
>> account name. 
> 
> No, it is both. This is why face logins are bad in a secure setting.

Since I seem to have helped start this thread with some random comments 
off of my head, including the mistaken assumption that gdm reports 
'invalid username', I'll just say here-

+1 to face logins _providing_ usernames, as opposed to this whole debate 
about 'invalid username' leaking _non-usernames_.  I.e, if people 
actually wanted to implement something like I suggested, i.e. unknown 
username spawning create-user process, then the disabling of the feature 
for security reasons should be advertised right next to the disablement 
of the face-login feature, for the same reasons.

Again, it all boils down to threat models, and the balance of 
convenience with respect to providing the most benefit for what is 
targeted as the default installation.  Thus the question is, for the 
default installation, does the increased vulnerability outweigh the 
increased convenience.  Clearly if face-login is enabled by default, it 
seems like this leakage of non-usernames is not a serious increase in 
vulnerability, as long as it is obvious to disable it at the same time 
and for the same reasons as disabling the face-login feature.

$0.02...

-dmc

"For me, given my threat model and how much my time is worth, life is 
too short for SELinux."




More information about the fedora-devel-list mailing list