8:01 a.m.
Linux-PAM 0.78 and later contains include directive which obsoletes
using the pam_stack module. This module is rather a hack as it requires
access to pam library internals for its operation and will never be
accepted to upstream.
The include directive implementation is much cleaner although its
semantics are subtly different. The include works as a real include so
the base file and the included one are processed as if they were first
flattened into one file. The pam_stack module however works as if the
pam was recursively called again with the stacked service.
Arguably the pam_stack model is little bit more "user friendly" as
"sufficient" entries in the stacked service don't bypass modules in the
primary service which came after the pam_stack module. This means that
all existing configuration files for services cannot be blindly modified
but they have to be carefully examinated and modified with the above in
mind.
The pam_stack module probably won't be removed too soon because it would
break upgrades with modified pam configs however I'll probably add some
deprecation message in the system log when it will be used.
Also big warning for people which modify the /etc/pam.d/system-auth file
by hand - never remove the "auth required pam_deny.so" as it will make
some pamified services open to anyone (depending on preceding modules in
the system-auth and the pam config which includes it).
--
Tomas Mraz <tmraz(a)redhat.com>
4:49 p.m.
Tomas Mraz <tmraz(a)redhat.com> writes:
Linux-PAM 0.78 and later contains include directive which obsoletes
using the pam_stack module.
What does that version translate into in terms of RHEL/Fedora releases?
What would be an appropriate replacement for a trivial default
config file, eg
#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
regards, tom lane
2:58 a.m.
On Sat, 2005-10-08 at 17:49 -0400, Tom Lane wrote:
Tomas Mraz <tmraz(a)redhat.com> writes:
> Linux-PAM 0.78 and later contains include directive which obsoletes
> using the pam_stack module.
What does that version translate into in terms of RHEL/Fedora releases?
What would be an appropriate replacement for a trivial default
config file, eg
#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
Such a simple config file is replaced with:
#%PAM-1.0
auth include system-auth
account include system-auth
However things get more complicated if in the existing config there are
modules AFTER the pam_stack in the auth, account or password phases.
Basically they cannot be there if include is used because in the
included file there may be "sufficient" entries. So the new config files
must be rearranged so these modules are moved up before the include.
But sometimes (for example with pam_nologin) it is not possible because
it would change semantics a little bit so it's better to move the
pam_nologin to account phase.
I'm also introducing a new common config file (config-util) which should
be used for all system-config-... utilities which use userhelper.
So all these utilities should have the same config:
#%PAM-1.0
auth include config-util
account include config-util
session include config-util
--
Tomas Mraz <tmraz(a)redhat.com>
7:06 p.m.
Tomas Mraz wrote:
Linux-PAM 0.78 and later contains include directive which obsoletes
using the pam_stack module. This module is rather a hack as it requires
access to pam library internals for its operation and will never be
accepted to upstream.
Thank you. Simplifying PAM configuration was badly needed.
I have a few wishlist entries to submit, if you have time to
consider them:
- For some reason, pam_ldap interacts strangely with pam_unix.
Even tough pam_unix comes before it and is "sufficient",
nobody can login when the network is down or slapd is down.
Also, you can login as root with root's password from ldap
even tough there's a valid root entry in /etc/passwd.
- Many pam.d files still use the absolute path "/lib/security/$ISA/"
that doesn't seem to be useful anymore and looks weird on
bi-arch systems such as x86_64.
- Something similar of pam_ssh would be much cleaner than the
current hack of running ssh-agent in GDM's session. gpg-agent
support would also be welcome.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
7:39 p.m.
On Tuesday 11 October 2005 06:06pm, Bernardo Innocenti wrote:
Tomas Mraz wrote:
> Linux-PAM 0.78 and later contains include directive which obsoletes
> using the pam_stack module. This module is rather a hack as it requires
> access to pam library internals for its operation and will never be
> accepted to upstream.
Thank you. Simplifying PAM configuration was badly needed.
I have a few wishlist entries to submit, if you have time to
consider them:
- For some reason, pam_ldap interacts strangely with pam_unix.
Even tough pam_unix comes before it and is "sufficient",
Not sure how to explain that.
nobody can login when the network is down or slapd is down.
That is normal...unless you have configured your systems to cache
authentication credentials locally so that they can authenticate
disconnected.
Also, you can login as root with root's password from ldap
even tough there's a valid root entry in /etc/passwd.
Yup. That's normal, because, when the pam_unix.so check for root fails, the
"sufficient" line will not affect the overall outcome of the authentication
attempt, then PAM moves on to the next line and succeeds with the sufficient
pam_ldap.so line.
This is part of the reason why having root credentials in your central
authentication store is a BIG NO-NO. You should *only* have root credentials
locally on each machine.
[SNIP]
--
Lamont R. Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
8:35 p.m.
On 10/11/05, Lamont R. Peterson <lamont(a)gurulabs.com> wrote:
On Tuesday 11 October 2005 06:06pm, Bernardo Innocenti wrote:
> Tomas Mraz wrote:
> > Linux-PAM 0.78 and later contains include directive which obsoletes
> > using the pam_stack module. This module is rather a hack as it requires
> > access to pam library internals for its operation and will never be
> > accepted to upstream.
>
> Thank you. Simplifying PAM configuration was badly needed.
>
> I have a few wishlist entries to submit, if you have time to
> consider them:
>
> - For some reason, pam_ldap interacts strangely with pam_unix.
> Even tough pam_unix comes before it and is "sufficient",
Not sure how to explain that.
> nobody can login when the network is down or slapd is down.
That is normal...unless you have configured your systems to cache
authentication credentials locally so that they can authenticate
disconnected.
I think the problem comes with outside expectations. The idea would be
that if the pam_unix comes back with a correct passwd as "sufficient"
etc it then you shouldn't need pam_krb/pam_ldap. The problem is that
the pam model seems to try to check the ones below even when not
needed (possibly because something lower in the stack could invalidate
it?) So when the network is down, it acts like a show-stopper (either
through a network timeout longer than the login timeout) or coming
back as a failure and pam counting it.
Putting in timeout modes and such didnt seem to help me when I tried
this back in RHL 7.3 days.. It has been a problem with our laptop
users because it effectively requires them to re-run authconfig
whenever they go off the wire.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
12:09 a.m.
--On Wednesday, October 12, 2005 2:06 AM +0200 Bernardo Innocenti
<bernie(a)develer.com> wrote:
- For some reason, pam_ldap interacts strangely with pam_unix.
Even tough pam_unix comes before it and is "sufficient",
nobody can login when the network is down or slapd is down.
Also, you can login as root with root's password from ldap
even tough there's a valid root entry in /etc/passwd.
I thought I had a misconfiguration when I was seeing this.
I'd also like to get pam_smbpass into system_config_authentication, and
just filed an RFE Bugzilla for it. Rather than customize SCA for each new
PAM module, perhaps it should have some separate config where one can list
the available modules. I just found a module from Microsoft for sending
password changes to Win32 systems. (With source!) I wrapped it in an RPM
and will be testing it shortly.
<http://www.microsoft.com/windowsserver2003/R2/unixcomponents/idmu.mspx>
<http://www.microsoft.com/technet/interopmigration/unix/sfu/psync.mspx>
4:05 a.m.
On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote:
Tomas Mraz wrote:
> Linux-PAM 0.78 and later contains include directive which obsoletes
> using the pam_stack module. This module is rather a hack as it requires
> access to pam library internals for its operation and will never be
> accepted to upstream.
Thank you. Simplifying PAM configuration was badly needed.
I have a few wishlist entries to submit, if you have time to
consider them:
- For some reason, pam_ldap interacts strangely with pam_unix.
Even tough pam_unix comes before it and is "sufficient",
nobody can login when the network is down or slapd is down.
The pam_ldap module
will reject login in the account phase. You can use
pam_localuser (supported by authconfig) to make pam_unix authorization
of local users sufficient.
Also, you can login as root with root's password from ldap
even tough there's a valid root entry in /etc/passwd.
That's expected as
both pam_ldap and pam_unix are sufficient entries.
If you want to prevent that you can insert pam_succeed_if
- Many pam.d files still use the absolute path
"/lib/security/$ISA/"
that doesn't seem to be useful anymore and looks weird on
bi-arch systems such as x86_64.
They will be converted during the change to use
include instead of
pam_stack.
- Something similar of pam_ssh would be much cleaner than the
current hack of running ssh-agent in GDM's session. gpg-agent
support would also be welcome.
This is a problem as the passphrases for ssh keys
can be different from
the user's system password. So the pam_ssh is definitely not a
replacement for ssh-agent.
--
Tomas Mraz <tmraz(a)redhat.com>
4:10 a.m.
On Wed, 2005-10-12 at 11:05 +0200, Tomas Mraz wrote:
On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote:
> Also, you can login as root with root's password from
ldap
> even tough there's a valid root entry in /etc/passwd.
That's expected as both pam_ldap and pam_unix are sufficient entries.
If you want to prevent that you can insert pam_succeed_if
I've forgot to finish
this. You can insert pam_succeed_if in between
pam_unix and pam_ldap.
auth sufficient pam_unix.so .....
auth required pam_succeed_if.so uid != 0 quiet
auth sufficient pam_ldap.so .....
This way only the local unix password will work for root.
--
Tomas Mraz <tmraz(a)redhat.com>
8:06 p.m.
Tomas Mraz wrote:
On Wed, 2005-10-12 at 11:05 +0200, Tomas Mraz wrote:
> On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote:
>> Also, you can login as root with root's password from ldap
>> even tough there's a valid root entry in /etc/passwd.
> That's expected as both pam_ldap and pam_unix are sufficient entries.
> If you want to prevent that you can insert pam_succeed_if
I've forgot to finish this. You can insert pam_succeed_if in between
pam_unix and pam_ldap.
auth sufficient pam_unix.so .....
auth required pam_succeed_if.so uid != 0 quiet
auth sufficient pam_ldap.so .....
This way only the local unix password will work for root.
Works fine, thanks!
(please ignore my previous post asking for clarifications).
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
5:17 a.m.
This is a problem as the passphrases for ssh keys can be different
from
the user's system password. So the pam_ssh is definitely not a
replacement for ssh-agent.
This is not an issue for pam_ssh, as pam_ssh may ask for the passphrase.
There is a difference, though. Indeed with pam_ssh the passphrase is
always asked for, with ssh-agent the passphrase is only asked for
if the user launch ssh-add.
With the following /etc/pam.d/gdm I login using a password checked by
service=system-auth, then give the passphrase to pam_ssh in the auth phase,
and the login succeed even if I give a bad passphrase. If the passphrase was
right, the agent is launched in the session phase:
#%PAM-1.0
auth required pam_env.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
auth optional pam_ssh.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
session optional pam_ssh.so
Of course there are other usages of pam_ssh, for example it may be required
in the auth phase.
--
Pat
8:02 p.m.
Tomas Mraz wrote:
> - For some reason, pam_ldap interacts strangely with pam_unix.
> Even tough pam_unix comes before it and is "sufficient",
> nobody can login when the network is down or slapd is down.
The pam_ldap module will reject login in the account phase. You can use
pam_localuser (supported by authconfig) to make pam_unix authorization
of local users sufficient.
Thank you. I've regenerated my /etc/pam.d/system-auth with
system-config-authentication and enabled the localuser module.
Login with local user accounts still failed because nss_ldap
tries too hard to connect to the LDAP server and incurs in
the 60 seconds timeout of /bin/login.
I've fixed it by setting these options in my /etc/ldap.conf:
# Search timelimit
timelimit 3
# Bind timelimit
bind_timelimit 2
# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
bind_policy soft
I wonder if values like these should become the Fedora defaults?
A system that just hangs when you pull the ethernet cable doesn't
make a good impression with most users.
> Also, you can login as root with root's password from
ldap
> even tough there's a valid root entry in /etc/passwd.
That's expected as both pam_ldap and pam_unix are sufficient entries.
If you want to prevent that you can insert pam_succeed_if
Sorry, I don't quite understand how to set it up to reject uid == 0
just for pam_ldap and not for pam_unix.
I also don't understand what the "uid < 100" condition inserted
by system-config-auth is for.
My current config is:
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5afs.so use_first_pass tokens
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account [default=bad success=ok user_unknown=ignore] pam_krb5afs.so
account required pam_permit.so
password requisite pam_cracklib.so retry=3
password sufficient pam_unix.so md5 shadow nullok use_authtok
password sufficient pam_krb5afs.so use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
session optional pam_krb5afs.so
session optional pam_ldap.so
The man pam_succeed_if man-page says it can suceed _or_ fail,
but it only seems to
> - Many pam.d files still use the absolute path
"/lib/security/$ISA/"
> that doesn't seem to be useful anymore and looks weird on
> bi-arch systems such as x86_64.
They will be converted during the change to use include instead of
pam_stack.
Nice. system-config-authentication already wiped the paths out
when it rewrote system-auth.
> - Something similar of pam_ssh would be much cleaner than the
> current hack of running ssh-agent in GDM's session. gpg-agent
> support would also be welcome.
This is a problem as the passphrases for ssh keys can be different from
the user's system password. So the pam_ssh is definitely not a
replacement for ssh-agent.
Yes, we would need half of what pam_ssh does: instead of authenticating
the user against his ssh key, it should just load the key iff the
passphrase happens to match the account password.
Maybe this other project would be more appropriate:
http://sourceforge.net/projects/pam-ssh-agent/
PAM module that spawns a ssh-agent and adds identities using the
password supplied at login.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
12:56 p.m.
On Wednesday 12 October 2005 07:02pm, Bernardo Innocenti wrote:
Tomas Mraz wrote:
[SNIP]
>> Also, you can login as root with root's password from
ldap
>> even tough there's a valid root entry in /etc/passwd.
>
> That's expected as both pam_ldap and pam_unix are sufficient entries.
> If you want to prevent that you can insert pam_succeed_if
Sorry, I don't quite understand how to set it up to reject uid == 0
just for pam_ldap and not for pam_unix.
The correct solution is simply this: DO NOT add root (uid == 0) authentication
credentials in your central authentication stores. If you already have root
credentials in there, GET THEM OUT OF THERE. root should only be able to
authenticate locally on every single box. The security danger of not
following this policy can be quite high.
That said, it still might not be a bad idea to implement the extra config line
that Tomas Mraz suggested, earlier...as an extra protection measure. The
disadvantage of adding it is that you will have to do so on all systems you
want to have connected to your central authentication store (LDAP, Kerberos,
whatever).
Perhaps it should be added to the default PAM configuration for FC5. I would
vote for that.
I also don't understand what the "uid < 100"
condition inserted
by system-config-auth is for.
There are only two kinds of accounts as far as the kernel is concerned; root
and everyone else. We humans think of it in terms of three kinds of
accounts; "root" (superuser), "system" (not-superuser and no human
being
associated, typically, 0 < system account uid < 100) and
"regular-user" (human being).
Typically, one should not be able to login to "system" accounts.
Occasionally, it is necessary to run a bunch of shell commands/scripts as a
system account (installing some DB engines comes to mind), in which case root
can "su - system-account" to do so.
SELinux also helps with this "issue".
[SNIP]
> This is a problem as the passphrases for ssh keys can be
different from
> the user's system password. So the pam_ssh is definitely not a
> replacement for ssh-agent.
Yes, we would need half of what pam_ssh does: instead of authenticating
the user against his ssh key, it should just load the key iff the
passphrase happens to match the account password.
Maybe this other project would be more appropriate:
http://sourceforge.net/projects/pam-ssh-agent/
PAM module that spawns a ssh-agent and adds identities using the
password supplied at login.
I like this. It would be nice if FC5 would ship pam-ssh-agent. I'll vote for
it :).
--
Lamont R. Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
7:05 p.m.
Lamont R. Peterson wrote:
The correct solution is simply this: DO NOT add root (uid == 0)
authentication
credentials in your central authentication stores. If you already have root
credentials in there, GET THEM OUT OF THERE. root should only be able to
authenticate locally on every single box. The security danger of not
following this policy can be quite high.
I agree, but I think the correct solution is getting the clients not
to trust their LDAP server when authenticating uid=0.
Just removing root from the directory isn't going to make clients more
secure. IP spoofing and other tricks can be used to fake another LDAP
server with a root account. Of course you may be using TLS and
install SSL certificates on every clients, but I doubt any busy
system administrator would go this far to protect *clients* on the LAN.
That said, it still might not be a bad idea to implement the extra
config line
that Tomas Mraz suggested, earlier...as an extra protection measure. The
disadvantage of adding it is that you will have to do so on all systems you
want to have connected to your central authentication store (LDAP, Kerberos,
whatever).
Perhaps it should be added to the default PAM configuration for FC5. I would
vote for that.
I'd vote for that too.
> Maybe this other project would be more appropriate:
>
> http://sourceforge.net/projects/pam-ssh-agent/
>
> PAM module that spawns a ssh-agent and adds identities using the
> password supplied at login.
I like this. It would be nice if FC5 would ship pam-ssh-agent. I'll vote for
it :).
Good. Who should we bug to get it into FC5? :-)
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
6766
days inactive
6774
days old
13 comments
7 participants
participants (7)
-
Bernardo Innocenti -
Kenneth Porter -
Lamont R. Peterson -
Patrice Dumas -
Stephen John Smoogen -
Tom Lane -
Tomas Mraz