Re: [gentoo-user] Re: A quick test of su [SOLVED]

[Alan McKinnon]

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