On Tuesday 19 January 2010 20:26:29 Nikos Chantziaras wrote:
> On 01/19/2010 07:55 PM, walt wrote:
> > On 01/18/2010 04:41 PM, walt wrote:
> >> Here is what I see on both machines:
> >>
> >> $su
> >> Password: <===== I type Ctrl-d here
> >> Segmentation fault
> >>
> >> I've traced this problem to the pam_ssh package, which is supposed
> >> to return a charstring containing the typed password, but it instead
> >> returns a null pointer when I type Ctrl-d. Calamity ensues.
> >
> > The key here is the pam_ssh package, which apparently the rest of you
> > don't use for authentication.
>
> Just a quick question: what do you need PAM for? No it's not a
> rhetorical question. I always wondered what PAM is good for; to find
> out, I completely removed everything PAM related from my system ("-pam"
> in make.conf and then rebuild everything and then depclean.) The system
> works exactly the same as before. So I'm left wondering what PAM was
> doing in the first place?
>
pam allows you to customize your authentication strategy, in a way somewhat
similar to the windows model - load modules or whatever and a new auth scheme
comes into play.
Without pam, you use the traditional unix authentication scheme for local
login as done by (I think) login. Other auth-related packages run as root or
suid root, use their own scheme to authenticate you then take appropriate
action to give you what you want. sshd is a great example - with key-based
auth it goes nowhere near your shadow entry yet still gives you a full-blown
shell. This means that all auth packages must implement their own auth scheme,
which can be problematic for the same reason that bundled zlib libraries are
problematic - you don't always know they are there and if buggy represent a
huge risk.
pam centralises that and gives an API that any package can link to for auth
purposes. You have one set of auth libs in a known place that can be
extensively audited for bugs, lack of. Plus pam is designed to be customizable
so you the admin dictate how your auth works. If you need retina scanners,
thumbprint readers, one-time passwords as well as shadow password to log in,
then you configure pam to make it so (you will need drivers for those hardware
scanners). Ridiculous example of course, but perfectly possible with pam.
Most distros ship a standard pam config that gives you exactly what unix-style
auth and sshd did all along. So when you remove pam, you see no difference.
As an example, my Unix systems use short usernames and the company's AD uses
firstname.surname for windows login names. We decided to force users to log
onto the Cisco kit via a Linux gateway and to use the one-time-password gadget
setup for the Juniper VPN as well. Users auth to the Linux gateways using ssh
with an AD username, password and the token from the OTP fob and they
miraculously get logged in to the Linux box with a *different* (short)
username. That username is the same as the Cisco auth scheme (we can't change
it due to limitations in the tacacs+ protocol). Without pam, this would have
been exceptionally hard to do. So hard, that all of us refused to even begin,
citing horrendous security risks. With pam, it was almost trivial - 20 lines
of code.
So all the above is true but also a lot of marketing blurb. There are two
downsides to pam:
The configuration is horrible and abstracted many more times than makes sense.
You need to be very very careful that what you type is what you want. And
coding authentication apps is very hard indeed, you need coders of very high
skill to do it right.
The jury is still mostly out on whether pam achieved it's goals or not. Unix-
pam seems to mostly have got it right. Linux-pam is slapdash in comparison, no
thanks to Red Hat's infamous pam_console.so. flameeyes is of the opinion that
linux-pam should not really be suffered to live. I mostly agree with
flameeyes.
--
alan dot mckinnon at gmail dot com
