On Wed, Nov 18, 2009 at 12:56 AM, Allan McRae wrote:

Caleb Cushing wrote:

...

so here's the problem I've discovered

http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-k... < 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 acceptable.

#2 is my preferred.

Allan

-- Caleb Cushing http://xenoterracide.blogspot.com

On Wed, 2009-11-18 at 02:24 -0500, Caleb Cushing wrote:

...

Oh no. It has been 1 day and my "bug" is not fixed! I must blog about it so the world listens to me...

also no one has presented a /good/ reason for not fixing it, only reasons they don't think it should be fixed. you could do abc or d things that I can think of... but no one has said why security shouldn't be tighter for kde. what's the negative impact? why aren't failed logins being logged right now? why can users login if they have an account but no valid shell? seriously? what's the reason that this should not be fixed? that there MAY be acceptable alternatives? I dont' find the GUI option acceptable, because it's too kde specific, and (probably) doesn't affect a thing if I change login managers. only one of the options you suggest actually do what I need to do... but for some reason it didn't take immediate effect when I tried it. <snip>

Minimal modification of packages. Allow users to choose for themselves instead of doing work for them. I fail to see the security implications here for the common user, why would someone want to lock out a user without deleting the account except a system admin, who presumably would know what to do and would not need a 'simple one-step process'. I'd wager most Arch users simply have 1 account they use all the time, and perhaps a guest account for others to use. This isn't a security hole, and it isn't the responsibility of Arch devs to make decisions for the users except in extreme cases.

On Wed, 2009-11-18 at 03:49 -0500, Caleb Cushing wrote:

...

Minimal modification of packages. Allow users to choose for themselves instead of doing work for them. I fail to see the security implications here for the common user, why would someone want to lock out a user without deleting the account except a system admin, who presumably would know what to do and would not need a 'simple one-step process'.

maybe, but it all depends should the admin have to do a full system security audit? after making these changes I shouldn't have any problems with kdm, the system is more secure and there are no disadvantages that I can see. I just can't understand why I had to go through all of this to start, sure I could make my system even MORE secure but it's just unnecessary. also one implication in the modified file I sent is currently failed logins (w/ kdm) don't get logged... but I don't suppose that the average user reads their failed user authentication logs, or cares that say a roommate has been trying to crack there account by hand (because they aren't smart enough to know how to mount a system drive with a livecd (yes I've had this happen this is why we hash passwords and make them in the first place not all users are as smart as us)). The *disadvantage* is that the devs/maintainers have to patch up-stream. This should be kept to a minimum, primarily to reduce their workload, and also because it is ASSUMED that if you use Arch, you're capable of doing the Right Thing (tm) according to your situation, or at least finding out how to.

...

I'd wager most Arch users simply have 1 account they use all the time, and perhaps a guest account for others to use.

perhaps so... but as I've said this doesn't negatively impact them. the size is negligible and the benefits are helping people who are ignorant of weak pam settings and may not have checked that an account they thought was disabled actually was. I'm just happy I checked. As above, its not about the negative impact on the general user-base, but simply the fact that Arch is not Ubuntu or Fedora with dozens and hundreds of devs/maintainers, some of whom are full-time. I believe the Arch wiki talks about giving users *control* and *responsibility* over their systems, and at least part of this is due to the fact that it does not make sense for a dev to be putting in AND maintaining patches such as these if its not a big security hole or something which affects a wide userbase.

...

This isn't a security hole, and it isn't the responsibility of Arch devs to make decisions for the users except in extreme cases.

how is this making decisions for users? arch makes decisions for users all the time. I'd guess that arch has done SOME setup of pam. It's a distributions job to make relatively sane and secure defaults. a distibution shouldn't do insane security, like require usb key auth (unless that kind of security is distro focus). but if there's no serious performance impact, and no visible user impact, then why should a distro implement a secure as possible by default setup? Arch isn't your normal distro. And the core assumption that Arch is responsible for your security is partly false. Yes, big problems have to be faced up to. This isn't one of them.

On Tue, Nov 17, 2009 at 11:56 PM, Allan McRae wrote:

Caleb Cushing wrote:

...

so here's the problem I've discovered

http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-k... < 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...

"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 2) put an asterisk "*" at the beginning of the second field (before the encrypted password) in the file /etc/shadow. 3) set an account expiry date using chage 3) userdel is permanent one step procedure that works very well...

#2 is my preferred.

As far as the people I know, passwd -d and passwd -l are the most common ways to do this. They do NOT change the shell. Changing the shell to lock out an account is laughable

On Wed, 2009-11-18 at 14:17 +0100, bender02 wrote:

On Wed, Nov 18, 2009 at 2:07 PM, Xavier wrote:

...

And I am curious to know what the pam settings of other distro are (debian,fedora,gentoo,..).

Finally, maybe it makes sense to try keeping all the different pam login files as consistent as possible. But I don't know enough about pam to tell.

Some other distros (opensuse, ubuntu, fedora at least) use 'common-auth' (and probably some other 'common-*' files) in /etc/pam.d/, which are then included in the particular pam files. Hence all pam files are consistent. On the other hand, if you need more fine-grained control, you need to edit and consolidate more files than with the current arch setup. [I like arch's system better, but who cares about that :)]

The reason for shipping custom pam files is because we don't have common-* files in arch. The gdm file is a straight copy from the login file, with some added modules for gnome-keyring to get that daemon started on login. With common-auth, we could just @include common-auth from the pam file, which is much easier.

At Mittwoch, 18. November 2009 14:07 Xavier wrote: I hope this could be a help for someone who knows how to configurate pam.-)

And I am curious to know what the pam settings of other distro are (debian,fedora,gentoo,..).

Opensuse with the KDE43 repo has no /etc/pam.d/kde file and they used for configuration of the common files an own tool with the name pam-config. Here be the content of login and the common files: /etc/pam.d/login: #%PAM-1.0 auth requisite pam_nologin.so auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session session required pam_lastlog.so nowtmp session optional pam_mail.so standard /etc/pam.d/common-auth: auth required pam_env.so auth required pm_unix2.so /etc/pam.d/common-acount: acount required pam_unix2.so /etc/pam.d/common-password: password requisite pam_pwcheck.so nullok cracklib password required pam_unix2.so use_authok nullok /etc/pam.d/common-session: session required pam_limits.so session required pam_unix2.so session optional pam_umask.so Perhaps it could be a good idea to compare what other distributions do and optimize the files from archlinux. See you, Attila