From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-106448-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1NXKLO-0001KE-Iu
for garchives@archives.gentoo.org; Tue, 19 Jan 2010 20:06:30 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E80C5E0BE0;
Tue, 19 Jan 2010 20:05:57 +0000 (UTC)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224])
by pigeon.gentoo.org (Postfix) with ESMTP id 956FFE0BE0
for <gentoo-user@lists.gentoo.org>; Tue, 19 Jan 2010 20:05:57 +0000 (UTC)
Received: by ewy24 with SMTP id 24so5197380ewy.26
for <gentoo-user@lists.gentoo.org>; Tue, 19 Jan 2010 12:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:to:subject:date
:user-agent:references:in-reply-to:mime-version:content-type
:content-transfer-encoding:message-id;
bh=SBqXjvr1qVzmVXiQ6MH7FPm6o1MU1jwAkzHv/YCVZ0c=;
b=c13OsFNPNNdez+/k9O2NvvTRzlnGtxZMn/awsS9eZa/k4DD4cU3YSFJgZusbvjumXz
LUmvWbCeJRUmndJd1Li7CWOROOI4qwVt3GXAkDr3pdsz3TxvRMd83Ff1qp8qe/Wo0Xsp
y40HvbrAVxSEgvZ9crbAM9GLDXEKo29/otP0o=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:to:subject:date:user-agent:references:in-reply-to:mime-version
:content-type:content-transfer-encoding:message-id;
b=xtie5pLA8V4vhCtEzZx5rgZLrsTqjd7fXluEOUL1II0fGEsv4mt0SS/wKNOboL3qJG
KTL5Sk64OoLe7ToFHX4aOBUDnPVfGiJ0H/CVNxatxAyUYWfMkuBf3TYrol3uHPz6agCU
jp2SX3JRUxlnpeEPOTrX8MD9OFpcn4tcBVP5M=
Received: by 10.213.45.131 with SMTP id e3mr1452286ebf.84.1263931556873;
Tue, 19 Jan 2010 12:05:56 -0800 (PST)
Received: from nazgul.localnet (196-210-202-237.dynamic.isadsl.co.za [196.210.202.237])
by mx.google.com with ESMTPS id 14sm4447260ewy.11.2010.01.19.12.05.55
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Tue, 19 Jan 2010 12:05:55 -0800 (PST)
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: A quick test of su [SOLVED]
Date: Tue, 19 Jan 2010 22:04:07 +0200
User-Agent: KMail/1.12.4 (Linux/2.6.32-zen4; KDE/4.3.4; x86_64; ; )
References: <hj2m2t$c8p$2@ger.gmane.org> <hj4rmv$q2d$1@ger.gmane.org> <hj4tgd$ra$1@ger.gmane.org>
In-Reply-To: <hj4tgd$ra$1@ger.gmane.org>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201001192204.07747.alan.mckinnon@gmail.com>
X-Archives-Salt: 47af3b13-87d2-47c7-b8f8-efb35509f691
X-Archives-Hash: 0f658101d7b6be518d1a4a04b3f2fd94
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