[arch-general] pam settings INSECURE
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. so I'm starting with /etc/pam.d/login auth required pam_shells.so #add this: why let someone login who has an invalid shells. /etc/pam.d/kdm # I'm pretty sure it should be 99% the same as login since it allows logins. #%PAM-1.0 auth requisite pam_nologin.so auth required pam_unix.so nullok auth required pam_shells.so # as my blog says setting an invalid shell is a common way of disabling accounts. auth required pam_tally.so onerr=succeed file=/var/log/faillog # use this to lockout accounts for 10 minutes after 3 failed attempts #auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/ account required pam_access.so account required pam_time.so account required pam_unix.so password required pam_unix.so #password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 ret #password required pam_unix.so md5 shadow use_authtok session required pam_unix.so session required pam_env.so session required pam_limits.so also I believe pam_tally2 replaces pam_tally may wish to consider migrating (non urgent next release?) -- Caleb Cushing http://xenoterracide.blogspot.com
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. Allan
On Wed, Nov 18, 2009 at 12:56 AM, Allan McRae <allan@archlinux.org> 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
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.
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...
also 1 and 2 probably don't affect alternative forms of authentication... such as key auth, and thus do not effectively disable the account. -- 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.
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)).
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.
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? -- Caleb Cushing http://xenoterracide.blogspot.com
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.
2009/11/18 Ng Oon-Ee <ngoonee@gmail.com>:
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.
If you would take the time to look at the packages that are involved in this (namely shadow and kdebase-workspace), you'd see that both /etc/pam.d/login and /etc/pam.d/kde are manually suplied alongside the PKGBUILDs. So in this case, it's not "patching" but straight "replacing" the "upstream".
On Tue, Nov 17, 2009 at 11:56 PM, Allan McRae <allan@archlinux.org> 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
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
expiredate would be more appropriate but again it didn't seem to be instant. locking the password is good but it 'reportedly' won't stop key/token authentication nor should it.
Who said that setting the user's shell to /bin/false means disabling a user?
googling disabling a unix account often lists this and I know I've read a few books listing this. I'm not saying it's the most correct answer, but given that this shell only refers to a login shell if this isn't valid why should they be able to login? we set system accounts like postgresql to this for this reason, they aren't supposed to be logging in. again even though this is likely largely misinformation, it's far to common to ignore. also if you look at an account and there shell is /(s)bin/nologin wouldn't you assume that they aren't supposed to be able to login?
So basically you just need to add "auth required pam_shells.so" to all pam files related to login, correct ?
mostly yes.
Or what were the other problematic settings of pam.d/kde ?
but I believe all of the login files should be mostly similar. the suggestion of using common files is actually good and tweaking for the last few modules. for example anything that provides login should also be logging to faillog. basically unless it's medium specific they should basically be doing the same things. I also noticed arch hasn't changed to used pam_tally2 which I believe is a replacement for pam_tally. I don't have much details on this though. I should also say that the practices of kde-np concern me and I'm going to review them. I assume that's the file for 'no password'? it seems to be too permissive. it should check other stuff and just not password. but I haven't had time to check it over yet. -- Caleb Cushing http://xenoterracide.blogspot.com
On Wed, Nov 18, 2009 at 6:40 AM, Caleb Cushing <xenoterracide@gmail.com> 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.
so I'm starting with /etc/pam.d/login
auth required pam_shells.so #add this: why let someone login who has an invalid shells.
/etc/pam.d/kdm # I'm pretty sure it should be 99% the same as login since it allows logins.
#%PAM-1.0 auth requisite pam_nologin.so auth required pam_unix.so nullok auth required pam_shells.so # as my blog says setting an invalid shell is a common way of disabling accounts. auth required pam_tally.so onerr=succeed file=/var/log/faillog # use this to lockout accounts for 10 minutes after 3 failed attempts #auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/ account required pam_access.so account required pam_time.so account required pam_unix.so password required pam_unix.so #password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 ret #password required pam_unix.so md5 shadow use_authtok session required pam_unix.so session required pam_env.so session required pam_limits.so
also I believe pam_tally2 replaces pam_tally may wish to consider migrating (non urgent next release?)
So basically you just need to add "auth required pam_shells.so" to all pam files related to login, correct ? Or what were the other problematic settings of pam.d/kde ? The comments about this being an upstream problem are invalid, as these pam files are all shipped by arch : http://repos.archlinux.org/wsvn/packages/kdebase-workspace/trunk/ http://repos.archlinux.org/wsvn/packages/shadow/trunk/login Note that this problem probably exists with all login managers. For example gdm does not have pam_shells.so either. http://repos.archlinux.org/wsvn/packages/gdm/trunk/ 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.
On Wed, Nov 18, 2009 at 2:07 PM, Xavier <shiningxc@gmail.com> 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 :)]
On Wed, 2009-11-18 at 14:17 +0100, bender02 wrote:
On Wed, Nov 18, 2009 at 2:07 PM, Xavier <shiningxc@gmail.com> 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.
On Wed, Nov 18, 2009 at 2:24 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-11-18 at 14:17 +0100, bender02 wrote:
On Wed, Nov 18, 2009 at 2:07 PM, Xavier <shiningxc@gmail.com> 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.
That sounds good. I filed http://bugs.archlinux.org/task/17188
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
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.
Who said that setting the user's shell to /bin/false means disabling a user?
participants (9)
-
Aaron Griffin
-
Allan McRae
-
Attila
-
bender02
-
Caleb Cushing
-
Jan de Groot
-
Ng Oon-Ee
-
RedShift
-
Xavier