Avoid changing password
int
some users on my Linux systems must not change their password.
The system is a RedHat EL3 with pam 0.75.
My idea is /etc/nopasswd as list of such users.
I try this, the first line in pam.d/passwd:
/etc/pam.d/passwd
auth requisite pam_listfile.so onerr=fail item=user sense=deny
file=/etc/nopasswd
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
This is /etc/pam.d/system-auth
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth
nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3
type=
password sufficient /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
But a user in /etc/nopasswd is still able to call passwd and change
it's own password.
If the list of these users can be expanded to everyone but root, should
be simpler to remove exec bit for everyone from /usr/bin/passwd
(-r-s--x--x)? Or, more, changing its group to a one of allowed users?
Thanks.
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
http://kbase.redhat.com/faq/FAQ_43_5752.shtm
http://www.linux.ie/articles/pam.php
Unruh
>Hi,
>some users on my Linux systems must not change their password.
Weird. Usually people want users to change their passwords. Is this because
you want to share their passwords around? Bad idea. Maybe if you told us
what you want to accomplish by this strange idea we could give better ways
of accomplishing it.
If the below is an accurate reflection of what is in the pam files, it is a
mess-- totally inappropriate line breaks. If it is a posting error, plse
make sure what you post is an accurate reflection of what is in those
files, or help will be very hard to get.
And what is "requisite" supposed to mean? Did you mean "required"
Also you said that that list was required for authentication. Not for
int
> "int" <ale...@gmail.com> writes:
> >some users on my Linux systems must not change their password.
> Weird. Usually people want users to change their passwords. Is this because
> you want to share their passwords around? Bad idea. Maybe if you told us
> what you want to accomplish by this strange idea we could give better ways
> of accomplishing it.
Yes I know. It's bad, weird, scrap ... but it's not my choice.
"... It wasn't my fault ..." (The Blues Brothers).
The systems are offline and the password shared between users, the same
account is used by more people, and for this reason I need to deny
password changes. Sorry.
Please, don't speculate about the reasons for this.
> If the below is an accurate reflection of what is in the pam files, it is a
> mess-- totally inappropriate line breaks. If it is a posting error, plse
> make sure what you post is an accurate reflection of what is in those
> files, or help will be very hard to get.
Yes it was a posting error. I cut and paste but didn't pay too much
attention later.
The first line is the only I add to the Red Hat EL3 defaults.
I don't know anything about PAM, it's my first attempt after starting
reading about since today.
I'll provide a new post with correct line breaks next time I access one
of those systems.
> And what is "requisite" supposed to mean? Did you mean "required"
As I understood, "required" wants all modules get processed and all of
them returning ok.
"requisite" is the same, but if a module fails, the succeeding are not
processed.
Is this right? It should be like having or not logical shortcuts in C
expression like a & b & c & ... .
> Also you said that that list was required for authentication. Not for
> password.
Well.. as I understood, in /usr/bin/passwd, auth plays the role to ask
the first password. For this, I thought to block the auth step at
first, without going on asking new password.
But a non-PAM solution, if exists, would be appreciated too ...
Thanks again.
Unruh
>Unruh writes:
>> "int" <ale...@gmail.com> writes:
>> >some users on my Linux systems must not change their password.
>> Weird. Usually people want users to change their passwords. Is this because
>> you want to share their passwords around? Bad idea. Maybe if you told us
>> what you want to accomplish by this strange idea we could give better ways
>> of accomplishing it.
>Yes I know. It's bad, weird, scrap ... but it's not my choice.
>"... It wasn't my fault ..." (The Blues Brothers).
>The systems are offline and the password shared between users, the same
>account is used by more people, and for this reason I need to deny
>password changes. Sorry.
>Please, don't speculate about the reasons for this.
I am not speculating I am trying to see if suggestions can be made to
imporve the situation.
a) many users can share a uid. Each can have their own password. This would
make them all equivalent as far as the system is concerned but they could
have their own passwords which they may be able to better memorize. The
main problem is that of course that account is then only as strong as the
weakest password. But with people sharing the password that is not a
problem, since the insecurity elsewhere is far greater.
b) have people log on as themselves using their own account and password.
Then they ssh into the common account using rsa/dsa public key access.
>> If the below is an accurate reflection of what is in the pam files, it is a
>> mess-- totally inappropriate line breaks. If it is a posting error, plse
>> make sure what you post is an accurate reflection of what is in those
>> files, or help will be very hard to get.
>Yes it was a posting error. I cut and paste but didn't pay too much
>attention later.
>The first line is the only I add to the Red Hat EL3 defaults.
>I don't know anything about PAM, it's my first attempt after starting
>reading about since today.
>I'll provide a new post with correct line breaks next time I access one
>of those systems.
>> And what is "requisite" supposed to mean? Did you mean "required"
>As I understood, "required" wants all modules get processed and all of
>them returning ok.
>"requisite" is the same, but if a module fails, the succeeding are not
>processed.
>Is this right? It should be like having or not logical shortcuts in C
>expression like a & b & c & ... .
I have never seen the requisite command. And have not seen it looking
through the pam documentation.
>> Also you said that that list was required for authentication. Not for
>> password.
>Well.. as I understood, in /usr/bin/passwd, auth plays the role to ask
>the first password. For this, I thought to block the auth step at
>first, without going on asking new password.
>But a non-PAM solution, if exists, would be appreciated too ...
You could always just remove passwd ( or make it useable only by root) or
make it runable only by a group which does not include the accounts in
questions.
/etc/group
passwdallow:*: able,baker,eddy,gamma
and chgrp passwdallow /bin/passwd
chmod o-rwx /bin/passwd
Robert Nichols
int <ale...@gmail.com> wrote:
:Hi,
:some users on my Linux systems must not change their password.
:The system is a RedHat EL3 with pam 0.75.
From `man passwd`:
-n This will set the minimum password lifetime, in days,
if the user's account supports password lifetimes.
Available to root only.
Setting the minimum interval for password changes to a very large number
should accomplish what you want.
--
Bob Nichols AT comcast.net I am "RNichols42"
Rod Smith
Unruh <unruh...@physics.ubc.ca> writes:
>
> I have never seen the requisite command. And have not seen it looking
> through the pam documentation.
From the pam.conf man page:
: For the simple (historical) syntax valid control values are: requisite
: - failure of such a PAM results in the immediate termination of the
: authentication process; required - failure of such a PAM will ulti-
: mately lead to the PAM-API returning failure but only after the remain-
: ing stacked modules (for this service and type) have been invoked; suf-
: ficient - success of such a module is enough to satisfy the authentica-
: tion requirements of the stack of modules (if a prior required module
: has failed the success of this one is ignored); optional - the success
: or failure of this module is only important if it is the only module in
: the stack associated with this service+type.
--
Rod Smith, rods...@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux, FreeBSD, and networking
Michael Paoli
> some users on my Linux systems must not change their password.
# chage -m 99999 -M 99999 -d 2038-01-17 login
Theoretically that should defer the problem beyond the year 2311,
but other interesting things may happen before that (like in 2038 ...
but hopefully those issues will all have been dealt with by then).
Unruh
int
Paoli:
http://groups.google.com/group/comp.os.linux.security/msg/9ff6382a163004f5
http://groups.google.com/group/comp.os.linux.security/msg/5ba02e3bad2caa6d
http://groups.google.com/group/comp.os.linux.security/msg/140a1cb26c3b5aab
Unruh writes:
> I am not speculating I am trying to see if suggestions can be made to
> imporve the situation.
>
> a) many users can share a uid. Each can have their own password. This would
> make them all equivalent as far as the system is concerned but they could
> have their own passwords which they may be able to better memorize. The
> main problem is that of course that account is then only as strong as the
> weakest password. But with people sharing the password that is not a
> problem, since the insecurity elsewhere is far greater.
>
> b) have people log on as themselves using their own account and password.
> Then they ssh into the common account using rsa/dsa public key access.
Thanks for the suggestions. But the systems are no longer in dev phase,
so this kind of changes are forbidden. Password policy is so weak
because these system users are not personal accounts, only a sort
of "operative" users.
Regarding ssh, I'm using ssh with public key auth on these users,
and it save me a lot of time for maintenance.
> You could always just remove passwd ( or make it useable only by root) or
> make it runable only by a group which does not include the accounts in
> questions.
>
> /etc/group
>
> passwdallow:*: able,baker,eddy,gamma
> and chgrp passwdallow /bin/passwd
> chmod o-rwx /bin/passwd
Yes, this was one of my idea at being, that was in my first post.
But I choose for Robert and Michael suggestions. Thank you.
Michael Paoli writes:
> # chage -m 99999 -M 99999 -d 2038-01-17 login
> Theoretically that should defer the problem beyond the year 2311,
> but other interesting things may happen before that (like in 2038 ...
> but hopefully those issues will all have been dealt with by then).
The more interesting thing is that these systems should work for less
than 20 years from now on. The 2038 problem sholud not affect.
But if there is a way to delay a problem for so long, would make easier
a contract renewal for the next 305 years. I'll talk to my boss ... :-)
Greetings.