[arch-general] pam settings INSECURE

Caleb Cushing xenoterracide at gmail.com
Wed Nov 18 02:04:06 EST 2009

On Wed, Nov 18, 2009 at 12:56 AM, Allan McRae <allan at archlinux.org> wrote:
> Caleb Cushing wrote:
>> so here's the problem I've discovered
>> http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-kdm.html
>> < links to arch bug included posting here because I believe both kde's
>> and arch's developers responses are less than satisfactory. This is a
>> security bug an easy to fix without making users lives more difficult.
> Oh no.  It has been 1 day and my "bug" is not fixed! I must blog about it so
> the world listens to me...

because kde marked it invalid and the reply I received from arch
suggests it's 'not a bug'. regardless I blogged about it not just
because of Arch, but in case users of other distro's have a similar
'vulnerability'. I was not happy that it took me several tries and
much research to disable an account effectively from gui and cli.

> "I shouldn't have to disable an account in more than 1 way to disable it
> across the board."
> Let see... one step procedures for disabling the user account
> 1) change password for that user

I don't want to change there password that's not at all what I'm
trying to accomplish sure it would lock them out. but it's not the
same as disabling the account.

> 2) put an asterisk "*" at the beginning of the second field (before the
> encrypted password) in the file /etc/shadow.

is this actually all that much different from doing a passwd -l ?
which " puts a '!' in front of the encrypted  password, effectively
disabling the password."

> 3) set an account expiry date using chage

same as what I did with usermod for some reason it didn't take effect
immediately (not sure why haven't retested since discovering later)
this is ok but if you google disabling unix accounts you'll find quite
a few references to changing the shell to /bin/false. I also swear
(having trouble finding it) that I read somewhere that setting the
shell to /sbin/nologin should stop users from using X or kdm.

> 3) userdel is permanent one step procedure that works very well...

I only wanted to lock them out, not delete them. in case I decided to
re-enable later. this is also the reason the password option wasn't

> #2 is my preferred.
> Allan
Caleb Cushing


More information about the arch-general mailing list