Discussion:
BSD auth for NetBSD
(too old to reply)
Jun-ichiro itojun Hagino
2003-09-08 21:15:27 UTC
Permalink
as a firm believer of "rough consensus and running code", here's
the working code for BSD auth for NetBSD. sshd uses it, and i confirmed
that it is working very well. commit? (after $NetBSD$ cleanup and
stuff, of course)

ftp://ftp.itojun.org/pub/netbsd-bsdauth-20030909.tar.gz

itojun
Jun-ichiro itojun Hagino
2003-09-08 21:19:02 UTC
Permalink
Post by Jun-ichiro itojun Hagino
as a firm believer of "rough consensus and running code", here's
the working code for BSD auth for NetBSD. sshd uses it, and i confirmed
that it is working very well. commit? (after $NetBSD$ cleanup and
stuff, of course)
ftp://ftp.itojun.org/pub/netbsd-bsdauth-20030909.tar.gz
note that the use of BSD auth is optional; it is up to programs that
asks authentication (i.e. ftpd and such) to use it.

itojun
Noriyuki Soda
2003-09-08 21:38:13 UTC
Permalink
Post by Jun-ichiro itojun Hagino
On Tue, 9 Sep 2003 06:15:27 +0900 (JST),
as a firm believer of "rough consensus and running code"
Well, I don't see that there is rough consensus to import BSD auth
as the basic layer of authentication, because many people pointed out
that BSD auth can be implemented over PAM, and PAM can never be
implemented over BSD auth, and also people who agreed with BSD auth
couldn't produce any counterevidence.

I have read Frank's post, but he didn't mention which way we should
go, AFAICT.
Post by Jun-ichiro itojun Hagino
here's the working code for BSD auth for NetBSD.
Hmmm.
There is a PAM implementation for NetBSD, too.
Why don't you commit the PAM implementation instead?
Post by Jun-ichiro itojun Hagino
now, may i commit?
I think you shouldn't, unless your code is using PAM to implement
BSD auth.
If it implements BSD auth over PAM, I think it may be fine to commit
it, but I guess it doesn't, does it?

P.S.
I'm really going to sleep now... ;-)
--
soda
Bill Studenmund
2003-09-11 04:10:19 UTC
Permalink
Post by Noriyuki Soda
Post by Jun-ichiro itojun Hagino
On Tue, 9 Sep 2003 06:15:27 +0900 (JST),
as a firm believer of "rough consensus and running code"
Well, I don't see that there is rough consensus to import BSD auth
as the basic layer of authentication, because many people pointed out
that BSD auth can be implemented over PAM, and PAM can never be
implemented over BSD auth, and also people who agreed with BSD auth
couldn't produce any counterevidence.
I have read Frank's post, but he didn't mention which way we should
go, AFAICT.
As having been one of the more vocal folks on this in the past, let me
explain the "PAM over BSD Auth" idea, at least as I argued it for a few
years.

1) We don't really want to pick sides. We want admins who want to use
bsd_auth modules to be able to (and to have all of the implied privilege
fracturing), and folks who want to use PAM modules to be able to also.

2) We would like apps using NetBSD's libc to be able to take advantage of
either BSD Auth or PAM via nsswitch. That way the choice doesn't end up
burried in a nest of #ifdef, and you don't have to recompile code to
change.

Note: the above implies that applications won't be configured for PAM or
for BSD Auth, but that the admin could be using either one.

3) (2) really nees dynamic nsswitch modules.

4) PAM is a dynamic module layer, so why not just import PAM and not have
a separate nsswitch module layer? -> Do PAM first, then do BSD Auth on top
of that.

At first we thought we could just use the PAM API as the nsswitch module
API, but I'm not not so sure.

Note: last week I was thinking we would just have to have both, since
unifying would be such a mess. I now thing we will have three classes of
apps: ones written explicitly for BSD Auth, ones written explicitly for
PAM, and ones written for libc/nsswitch. The NetBSD-shipped apps would be
in the latter category, so that one binary distribution could serve as the
basis for both BSD Auth and PAM using instalations.

The difference is that we don't have to unify the full BSD Auth or PAM
APIs, we just have to have an nsswitch API that would cover what our apps
need and could be satisfied by both PAM and BSD Auth; we don't need to
handle the full case of making one look like the other.
Post by Noriyuki Soda
Post by Jun-ichiro itojun Hagino
here's the working code for BSD auth for NetBSD.
Hmmm.
There is a PAM implementation for NetBSD, too.
Why don't you commit the PAM implementation instead?
Post by Jun-ichiro itojun Hagino
now, may i commit?
I think the concensus is that would be premature. While having a
libbsdauth by itself isn't bad, the next step (login support and friends)
really needs to wait for nsswitch support, which in turn needs a unified
BSD Auth/PAM ABI subset. Otherwise we end up possibly hosing users at an
upgrade point.

Take care,

Bill
Todd Vierling
2003-09-11 04:42:25 UTC
Permalink
On Wed, 10 Sep 2003, Bill Studenmund wrote:

: Note: last week I was thinking we would just have to have both, since
: unifying would be such a mess. I now thing we will have three classes of
: apps: ones written explicitly for BSD Auth, ones written explicitly for
: PAM, and ones written for libc/nsswitch. The NetBSD-shipped apps would be
: in the latter category, so that one binary distribution could serve as the
: basis for both BSD Auth and PAM using instalations.

If that were the case, with dynamic nsswitch modules, then neither BSD auth
nor PAM even need to be in the base system. (There's already a growing
pkgsrc PAM module base, and all you'd need would be a package that glues PAM
to the dynamic nsswitch API.)
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Bill Studenmund
2003-09-11 05:28:12 UTC
Permalink
Post by Todd Vierling
: Note: last week I was thinking we would just have to have both, since
: unifying would be such a mess. I now thing we will have three classes of
: apps: ones written explicitly for BSD Auth, ones written explicitly for
: PAM, and ones written for libc/nsswitch. The NetBSD-shipped apps would be
: in the latter category, so that one binary distribution could serve as the
: basis for both BSD Auth and PAM using instalations.
If that were the case, with dynamic nsswitch modules, then neither BSD auth
nor PAM even need to be in the base system. (There's already a growing
pkgsrc PAM module base, and all you'd need would be a package that glues PAM
to the dynamic nsswitch API.)
True.

Take care,

Bill
Greg A. Woods
2003-09-11 06:50:27 UTC
Permalink
[ On Thursday, September 11, 2003 at 00:42:25 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
If that were the case, with dynamic nsswitch modules, then neither BSD auth
nor PAM even need to be in the base system. (There's already a growing
pkgsrc PAM module base, and all you'd need would be a package that glues PAM
to the dynamic nsswitch API.)
Nsswitch is not sufficient on its own, dynamic or otherwise. It still
leaves us with just a way to pull username/crypted-passwd strings and
the other associated account information from run-time configurable
sources. I.e. it still leaves us stuck with just secret passwords and
many #ifdefs everywhere for anything and everything else. I.e. nsswitch
still needs some way to allow the choice of authentication test to be
configured at runtime, and that's exactly what BSD Auth does, and only
what BSD Auth does. I.e. it fills a currently void niche in NetBSD.

There are also many other good reasons to convert the base NetBSD
release to use BSD Auth natively by default (in conjunction with keeping
nsswitch and/or moving to BIND's equivalent). Those who still think
they want/need PAM can still glue it in in the way Bill suggests with
dynamic nsswitch modules. All of those of us who want BSD Auth want it
not just because we might need to use some simple authenticator module
written for BSD Auth, but more because we all want all of the things BSD
Auth stands for (good clean secure elegant and simple design, for
example). All of those things are very good for NetBSD in general and
for all NetBSD users too, even those still happy with just using good
old fashioned secret passwords!

I.e. with BSD Auth included in NetBSD by default then everyone gets a
more flexible and much better designed (well, just "designed" is
sufficient -- the current mess certainly wasn't "designed" in any way)
framework for providing add-on authenticator hooks. If that still
proves not to be enough for the PAM folks then they can still easily add
on PAM support, either with dynamic nsswitch modules, or maybe even by
using a BSD Auth authenticator module that proxies through to PAM in a
safer and more reliable manner.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greywolf
2003-09-11 15:34:51 UTC
Permalink
Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> Nsswitch is not sufficient on its own, dynamic or otherwise. It still
GAW> leaves us with just a way to pull username/crypted-passwd strings and
GAW> the other associated account information from run-time configurable
GAW> sources. I.e. it still leaves us stuck with just secret passwords and
GAW> many #ifdefs everywhere for anything and everything else. I.e. nsswitch
GAW> still needs some way to allow the choice of authentication test to be
GAW> configured at runtime, and that's exactly what BSD Auth does, and only
GAW> what BSD Auth does. I.e. it fills a currently void niche in NetBSD.

I'm not a big fan of PAM, but I see what needs to be accomplished.
The light went on as soon as I fully understood the difference between
authentication (which is easy and is a read-only operation) and
authorisation (which is the write-half of the process, which is trickier
because it needs to be able to modify the credentials of the process).

As long as we focus only on authentication, the requirements for one,
the other, or both are not as clear. Once we integrate authorisation
into the requirements, it becomes clearer as to why different solutions
are desired.

We need to accept the following:

BSD Auth / PAM won't work 100%.
PAM / BSD Auth won't work 100%.
Static lookups won't work 100%.
Switch lookups won't work 100%.

Static and switch can share code; BSD Auth and PAM probably can't, even
though there may be similar methodology involved.

The solution is to implement BSD Auth and PAM separately, with some
overlap possible once all is said and done, but make sure they
each work as they need to individually.

A totally different issue involves allowing a mix of static/dynamic
linking.

For the PAM folks: Keep in mind that even if we do implement PAM, there
are third parties out there who have proprietary modules.

["But we can handle just doing object modules, that's fine."]

For i386 and possibly SPARC, sure; what about the other CPU architectures
that we support? They're dead in the water. I will grant that this is
an orthogonal issue, but it's something to consider. (Not that we could
do much about it except possibly write an i386 emulation layer (um...ew?)).

The same problem might exist WRT BSD Auth, except I haven't heard of too
many companies writing BSD Auth modules. If OpenBSD (*gasp* don't say
that!) does well (seeing as they are more interested in marketing share
than we seem to be (which isn't a bad thing (damn, I'm rambling this
morning!))), perhaps more third parties will become interested in doing
BSD Auth modules.

Sorry for the rambling. The news of the day has set my mind awhir.

--*greywolf;
--
"I didn't get where I am today without using NetBSD."
Greg A. Woods
2003-09-11 18:49:53 UTC
Permalink
[ On Thursday, September 11, 2003 at 08:34:51 (-0700), Greywolf wrote: ]
Subject: Re: BSD auth for NetBSD
I'm not a big fan of PAM, but I see what needs to be accomplished.
The light went on as soon as I fully understood the difference between
authentication (which is easy and is a read-only operation) and
authorisation (which is the write-half of the process, which is trickier
because it needs to be able to modify the credentials of the process).
As long as we focus only on authentication, the requirements for one,
the other, or both are not as clear. Once we integrate authorisation
into the requirements, it becomes clearer as to why different solutions
are desired.
Yeah but what I think you may be missing is that authorisation happens
at the filesystem level, not at the application level. Nothing really
needs "pluggable" or otherwise runtime configurable authorisation hooks.

For example the AFS authorisation hooks go deep in the associated
filesystem code in the kernel and are not "configurable" per se. They
work by examining credentials also stored deep in the kernel by the
authenticator. The only trick is in associating the stored credentials
with the process group, and so long as you let a privileged process, or
a child process, store that association, and so long as you store them
in the right place in the process and if necessary you modify fork() and
exec() so that they copy and preserve those associations, then you've
solved the problem.
BSD Auth / PAM won't work 100%.
It will. Really. It just needs a tiny bit of thinking outside the box
the PAM/AFS folks have built so tightly around their minds, as well as
acceptance from anyone wanting binary-PAM support that they/we can
indeed make their modules work through a BSD Auth proxy authenticator.

It's really not a very difficult problem conceptually. I've already
outlined almost all the things that can be done to solve these problems
in the context of BSD Auth. There is no fundamental and real roadblock
to making PAM work as an authenticator module for BSD Auth. None
whatsoever. All the proposed examples are smokescreens that blow away
in the wind after re-analyzing their underlying true requirements.
PAM / BSD Auth won't work 100%.
Using BSD Auth authenicators via PAM Won't ever work, period. The whole
idea of BSD Auth via PAM flies in the very face of everything BSD Auth
stands for from beginning to end. What a laugh of stupid design such a
monstrosity would be!
Static lookups won't work 100%.
Switch lookups won't work 100%.
Static and switch can share code; BSD Auth and PAM probably can't, even
though there may be similar methodology involved.
I'm not sure what you mean there.... I don't see any problem so long as
someone doesn't think they need static linked apps with PAM. One could
theoretically fool PAM in to thinking it's doing dynamic loading when
really it's just using a static linked copy of the module, but that's
really not the point, is it?
The solution is to implement BSD Auth and PAM separately, with some
overlap possible once all is said and done, but make sure they
each work as they need to individually.
Indeed, which is basically what those of use desiring BSD Auth _first_
have all been saying all along too.
A totally different issue involves allowing a mix of static/dynamic
linking.
Only if you also want PAM which seems to require dynamic linking as part
of its core specifications. I don't ever want PAM, so I don't care. :-)
For i386 and possibly SPARC, sure; what about the other CPU architectures
that we support? They're dead in the water. I will grant that this is
an orthogonal issue, but it's something to consider. (Not that we could
do much about it except possibly write an i386 emulation layer (um...ew?)).
Huh? It's an irrelevant issue! :-)

(note that proprietary binary-only PAM modules will be supported on
whatever hardware platforms the hardware vendors and software vendors
and the market agree are viable to be supported. E.g. PA-RISC seems to
be supported by some now, and Alpha probably is too. Note also they'll
all require syscall emulation for the "native" OS too, anyway.)
The same problem might exist WRT BSD Auth, except I haven't heard of too
many companies writing BSD Auth modules.
That's because they're too trivially simple to worry about. A junior
baby sys-admin could write one as a wrapper around any existing
command-line usable authentication tool with one hand tied behind his
back and the other stuck in his ear and with one eye closed, provided
his nose or elbow wasn't too big that he'd be hitting too many keys at a
time!
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Bill Studenmund
2003-09-11 16:49:32 UTC
Permalink
Post by Greg A. Woods
[ On Thursday, September 11, 2003 at 00:42:25 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
If that were the case, with dynamic nsswitch modules, then neither BSD auth
nor PAM even need to be in the base system. (There's already a growing
pkgsrc PAM module base, and all you'd need would be a package that glues PAM
to the dynamic nsswitch API.)
Nsswitch is not sufficient on its own, dynamic or otherwise. It still
leaves us with just a way to pull username/crypted-passwd strings and
the other associated account information from run-time configurable
sources. I.e. it still leaves us stuck with just secret passwords and
many #ifdefs everywhere for anything and everything else. I.e. nsswitch
still needs some way to allow the choice of authentication test to be
configured at runtime, and that's exactly what BSD Auth does, and only
what BSD Auth does. I.e. it fills a currently void niche in NetBSD.
There are also many other good reasons to convert the base NetBSD
release to use BSD Auth natively by default (in conjunction with keeping
nsswitch and/or moving to BIND's equivalent). Those who still think
they want/need PAM can still glue it in in the way Bill suggests with
dynamic nsswitch modules. All of those of us who want BSD Auth want it
not just because we might need to use some simple authenticator module
written for BSD Auth, but more because we all want all of the things BSD
Auth stands for (good clean secure elegant and simple design, for
example). All of those things are very good for NetBSD in general and
for all NetBSD users too, even those still happy with just using good
old fashioned secret passwords!
Have you not been listening? You're pushing in essence for a winner to get
declared, and for that winner to be BSD Auth. That's not going to fly at
present. BSD Auth will go into the tree much quicker and with much less
fuss after an active effort (not "they can fix it later") to support both
BSD Auth and PAM for nsswitch happens.

Pushing and shoving will only make it less likely to happen.

Take care,

Bill
Greg A. Woods
2003-09-11 20:23:05 UTC
Permalink
[ On Thursday, September 11, 2003 at 09:49:32 (-0700), Bill Studenmund wrote: ]
Subject: Re: BSD auth for NetBSD
Have you not been listening?
Very much so!

However I've not yet seen one shred of evidence which would show that
there could be any kind of problem with implementing PAM afterwards or
even with implementing PAM support via a BSD Auth proxy authenticator.

I.e. there's been no indication of any technically insurmountable
problem with the plan of implementing BSD Auth now as a direct
first-class component of NetBSD and then when someone comes along with
PAM code that works in that framework then it can be added at that time
if indeed there is any real call to implement PAM once BSD Auth has been
made available.

If PAM can be implemented as a dynamically loaded nsswitch dispatch
routine then so much the better, but as I'm sure you're aware there's
still need to exend the nsswitch internal and external APIs to include
authenticator hooks regardless as without them any runtime configurable
authentication framework remains un-associated with nsswitch and will
still require individual #ifdefs in all programs that initiate
authentication requests.
Pushing and shoving will only make it less likely to happen.
I can only pull from this position..... :-)
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-12 19:17:00 UTC
Permalink
Post by Greg A. Woods
However I've not yet seen one shred of evidence which would show that
there could be any kind of problem with implementing PAM afterwards or
even with implementing PAM support via a BSD Auth proxy authenticator.
What sort of evidence do you need other than "some authenticators need
to modify the context of the process". You can't currently do that
with the proxy scheme used by BSD Auth.

If you have a solution for this problem, hey, we're all ears.

-- Jason R. Thorpe <***@wasabisystems.com>
Love
2003-09-12 20:27:29 UTC
Permalink
Post by Jason Thorpe
Post by Greg A. Woods
However I've not yet seen one shred of evidence which would show that
there could be any kind of problem with implementing PAM afterwards or
even with implementing PAM support via a BSD Auth proxy authenticator.
What sort of evidence do you need other than "some authenticators need
to modify the context of the process". You can't currently do that
with the proxy scheme used by BSD Auth.
If you have a solution for this problem, hey, we're all ears.
I would say that there should be something like the setenv but instead a
callfunc module stringargument (module magic sent up over the fd that binds
togther libbsdauth and the autheticating module). And then the libbsdauth
lib should dlopen module in /lib/whever/lib<module>.so and dlsym
<somesymbol> an call that with the argument <stringargument>.

This is of course just oneway, I guess it could be make twoway someway.

I have no idea if this i good enough.

Love
Bill Studenmund
2003-09-12 20:44:00 UTC
Permalink
Post by Love
Post by Jason Thorpe
Post by Greg A. Woods
However I've not yet seen one shred of evidence which would show that
there could be any kind of problem with implementing PAM afterwards or
even with implementing PAM support via a BSD Auth proxy authenticator.
What sort of evidence do you need other than "some authenticators need
to modify the context of the process". You can't currently do that
with the proxy scheme used by BSD Auth.
If you have a solution for this problem, hey, we're all ears.
I would say that there should be something like the setenv but instead a
callfunc module stringargument (module magic sent up over the fd that binds
togther libbsdauth and the autheticating module). And then the libbsdauth
lib should dlopen module in /lib/whever/lib<module>.so and dlsym
<somesymbol> an call that with the argument <stringargument>.
This is of course just oneway, I guess it could be make twoway someway.
Huh, that didn't make sense. ??

The problem is that PAM modules can DO ANYTHING in the process's address
space. Some folks see that as a reason to avoid PAM, some folks see that
as a strength.

The problem (for supporting PAM) is that BSD Auth does everything in a
separate address space. So any such fixup has to get copied to the
original address space. Well, 1) BSD Auth limits what changes can get
propagated back to the original process; what happens if the PAM module
does something that can't get copied back? 2) How do you necessarily
_tell_ what got changed? PAM modules don't have to tell the host program
what they did, so it's not that easy.

Take care,

Bill
Love
2003-09-12 20:51:48 UTC
Permalink
Post by Bill Studenmund
Post by Love
Post by Jason Thorpe
Post by Greg A. Woods
However I've not yet seen one shred of evidence which would show that
there could be any kind of problem with implementing PAM afterwards or
even with implementing PAM support via a BSD Auth proxy authenticator.
What sort of evidence do you need other than "some authenticators need
to modify the context of the process". You can't currently do that
with the proxy scheme used by BSD Auth.
If you have a solution for this problem, hey, we're all ears.
I would say that there should be something like the setenv but instead a
callfunc module stringargument (module magic sent up over the fd that binds
togther libbsdauth and the autheticating module). And then the libbsdauth
lib should dlopen module in /lib/whever/lib<module>.so and dlsym
<somesymbol> an call that with the argument <stringargument>.
This is of course just oneway, I guess it could be make twoway someway.
Huh, that didn't make sense. ??
Right, I wasn't trying to make bsd auth implement pam, I was trying to to
add the functionallity of PAM to bsd auth (ie the ability to run stuff in
the application process).

Love
Greg A. Woods
2003-09-12 21:46:47 UTC
Permalink
[ On Friday, September 12, 2003 at 12:17:00 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
What sort of evidence do you need other than "some authenticators need
to modify the context of the process". You can't currently do that
with the proxy scheme used by BSD Auth.
not directly, no, but you don't really have to do it directly....
If you have a solution for this problem, hey, we're all ears.
Well, the most obvious (to me) solution is to write a little BSD Auth
authenticator module that would act as a _full_ proxy for a given PAM
thingy. ("PAM module" seems too redundant to me -- is there another
term for the loadable modules? Why didn't they call it "Pluggable
Authentication Framework"? ;-)

What do I mean by "_full_ proxy"? Well, assuming we know (by spec. or
by examination of the PAM code) what exactly the authenticator does to
the current process context then it's simply a matter of making it
possble for a specially written BSD Auth proxy authenticator module to
invoke PAM from its own separate process context and then if the
authentication succeeds to retrieve those changes PAM made to its own
context and then pass that information back to its parent process
through either existing BSD Auth hooks or alternately through new system
calls explicitly designed to facilitate this transfer.

In general I can't imagine anything that any PAM authenticator might do
to a process, either directly in process address space, or in the kernel
context for that process, which one would wish to allow under normal
circumstances, and which could not be encoded and passed back to the
parent process of the BSD Auth proxy authenticator in such a way that it
could be replicated in a controlled manner to the original caller
process as well. I can imagine things that would be very ugly to deal
with, but so far none of the examples that have been proposed pose any
great problem that I can see.

The difference of course is that with BSD Auth all these things that
might be done by a proxied PAM thingy have to be known in advance so
that the very narrow BSD Auth protocol, or special new system calls, can
be used to transfer their effect as necessary. This is a very good
thing since it forces full awareness of the interactions of any given
PAM code and it isolates that potentially foreign code to directly
messing with just one relatively short-lived authenticator proxy
process, not the whole application requesting authentication.

For example with the AFS credentials the BSD Auth to PAM proxy need only
be provided with a system call, or pair of system calls, that copy the
credential index entries from its own struct ucred back into its
parent's struct ucred. Voila! Now the parent process is blessed with
the authorization tokens it needs to successfully access the AFS
resources for which it has been authenticated and approved to access.

Of course with AFS it would make a lot more sense to just write a new
BSD Auth authenticator which would directly use a new setpag_parent()
system call to authorize the parent process with the new credentials in
much the same way I hinted way back when I cited the paper describing
the similar system call used for OSF DFS. I.e. with AFS there is no
real need to have the authenticator directly modify the calling process'
context -- those same index values for the AFS credentials can be safely
stored in any process context by a sufficiently privileged process and
that can be done of course without revealing the actual credentials to
the authentiator process. After all the current hack is simply
modifying the groups list to stick the credential index(es) as integer
values at the front of that list and that requires root privileges and
thus root already handles exactly the same information it would need
handle to assign those credentials to any other process as I propose.
Ideally of course the credential pointers or indexes would be stored in
proper new struct ucred fields, not by overloading the groups list with
their presence. (One could pass the credential index(es) back to the
parent via the environment variable trick already supported by BSD Auth
and then the caller could authorize itself before calling
setusercontext(), but that would require special AFS-specific code in
the client side of libauth or libc, which I gather we're trying to
avoid.)

In the case of these so-called "template users" for something like a
RAIDUS or TACACS authenticator it also makes the most sense to simply
write a new BSD Auth authenticator since such a thing is really quite
simple on its own (free example code abounds). Note there's no need
even to invent a new system call like setuid_parent() (more about this
below).

Before BSD Auth or PAM the use of RADIUS to authenticate to template
accounts (where the RADIUS server doesn't have enough information to
construct a full username & password databse) is done simply by having
appropriate code to deal with the concept in whatever application
requests authentication. Unix has always had the ability to give
multiple username and password authentication tokens to a single system
identity (User-ID). Several people have already added direct hooks to
*BSD systems to do this via RADIUS directly in login, ftpd, etc. All
that's needed is to know when to pass the username (and possibly the
authentication as well) to the RADIUS server without first looking it up
in the username database (or when to ignore the fact it isn't in the
username database and go on to ask RADIUS). One way of choosing which
authentication mechanism to use for unknown usernames is to control it
by way of configuration attributes, perhaps including username glob
patterns, in /etc/login.conf. The actual template accounts must already
exist in the username database of course and the new authenticator code
simply uses some attribute returned by the RADIUS server to choose the
correct user-ID to use from those available "template" accounts
(assuming there's more than one). All the rest from there on is normal
unix authorization. The authenticated username can still be used with
setlogin(), perhaps based on whether or not some other login.conf
attribute is set, but of course "ls -l" will show files accessible by
the authenticated user as being owned by the template account. As I say
most of all of this has already been done in various ways by multiple
people for various kinds of systems and at least one implementation I
know of is publicly available. Some existing commercial unix-based
routers may already work this way. :-)

All that's needed to implement template accounts with BSD Auth is to do
the above and then push the authentication part of the procedure out to
BSD Auth (which is the whole point of BSD Auth in the first place) and
lastly of course to find some way to get the chosen template UID back
from the authenticator module. Peter has shown how that works with
environment variable passing and with a minor adaptation to the library
code which handles this protocol it's simply a matter of reserving one
variable name in which to pass the UID value. So from there it is
simply a matter of putting the template UID choosing code in the
authenticator module, along with the RADIUS or whatever interface of
course, and then pass back the chosen UID in the reserved environment
variable to the library code that would know to use it when calling
setusercontext().

Note that all of this seemed very obvious to me right from the get go
when I first learned about BSD Auth, so I appologize if I've assumed it
would be just about as obvious to everyone else. The AFS wiggles took
me more time to grasp, but that was more due to the fact I found all the
AFS terminology extremely foreign and I had to dig quite a bit even to
find out what a PAG _really_ was, etc. Learning _exactly_ what was
being done to the process context was like pulling teeth from a very
angry and very hungry carnivore twice my size!

I find it quite bizzare that anyone consider it a requirement of PAM
that it be able to modify the calling process or its context directly.
PAM might be allowed to do that in its own back yard, but there's no
reason its modules can't be put in a limited playpen with razor-wire
fencing and a very wise and careful proxy at the gate who only lets it
get away with things it's explicitly required and permitted to do.

BSD Auth doesn't change the privileges necessary to authorize a process
as a newly authenticated UID -- it just retains the control over what
the authenticator module can do to the calling process and makes it
possible to separate the privileges needed for authentication from those
necessary to authorize a process thus making it possible to delegate
authentication privileges to a non-privileged UID and to then know that
no matter how buggy or compromised the authenticator is the best its
attacker can do, besides run other arbitrary foreign code as the
non-privileged UID, is validate the credentials of a specified username
without actually checking them. Even with the template account feature
the attacker can only _suggest_ a UID to authorise the caller as, but of
course the caller need not honour that suggestion if it seems out of
line. This makes it possible to greatly reduce the risk of running
third party authenticator code which might make network connections to
look up the data it needs such as from the likes of a RADIUS server on
an untrusted network. Spoofed malicious RADIUS replies no longer get
instant root privileges if they manage to exploit a vulnerability in the
authenticator code, and even if the attacker is really smart there's no
reason the system must be configured in such a way as to allow a RADIUS
user to be authenticated as UID==0.

(When you think about it beyond the first obvious levels it's clear that
within the framework of the unix security model the delegation of
authenticator privileges to a non-superuser requires that the
authenticator run in a separate process context and that it only be
allowed to communicate very limited things back to the caller (which
will bt running as root as it is privileged to authorize its process as
any UID). I.e. BSD Auth is a very obvious solution to this problem, and
as it turns out it's a very clean, simple, and elegant implementation as
well. You wouldn't want to try to use a less trusted authenticator with
something like AFS which requires much more trust, but at least with BSD
Auth you can do both separately as required.)
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Todd Vierling
2003-09-12 22:03:52 UTC
Permalink
On Fri, 12 Sep 2003, Greg A. Woods wrote:

: What do I mean by "_full_ proxy"? Well, assuming we know (by spec. or
: by examination of the PAM code) what exactly the authenticator does to
: the current process context

That rather defeats the purpose of PAM. Some authenticators (two-way smart
cards are a common example) are *stateful* and cannot run outside the
authenticated process without significant authenticator-specific context
copy operations. At that point, the whole point of running a pluggable
*off-the-shelf* module in the same process context is defeated and you might
as well not use PAM at all.

All this babble is all FUD. If you don't trust PAM modules, don't use them.
But that doesn't mean others should be barred from using them.
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Greg A. Woods
2003-09-12 23:39:39 UTC
Permalink
[ On Friday, September 12, 2003 at 18:03:52 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
That rather defeats the purpose of PAM. Some authenticators (two-way smart
cards are a common example) are *stateful* and cannot run outside the
authenticated process without significant authenticator-specific context
copy operations.
What stateful operations take place during (or at the end of) a session?
Exactly how much information do you suppose they might need to exchange
when such operations take place (i.e. what do you mean, more exactly, by
"significant")? Do you have any concrete examples of such devices with
online documentation of their theory of operation that you could point
me at?

Sounds like a pretty broken design for something that's just supposed to
authenticate a user so that processes can be authorized to be run as the
UID that represents that user. It makes no sense to even try to do
anything else stateful across the lifetime of a "session" within the
Unix security model, though doing something special at the end certainly
makes sense. However we already have the potential for mechanisms
everywhere necessary such that an authenticator could be notified when a
session ends (though we don't yet have an API to make it runtime
configurable within the context of something like BSD Auth or PAM, but
neither do we yet have any configurable (nsswitch-like) API for
authenticators which could be used to front either BSD Auth or PAM).

So, if a two-way smartcard needs to know when a session ends then that
simply means we need an additional API callout for authentication
mechanisms that invoked at session end as well as the obvious one that's
need to initiate authentication.

If all that's needed is some way to kill a session when a smartcard is
disconnected then that can easily be done from the context of a separate
daemon process (which would be needed anyway unless one allows for a PAM
thingy to run a thread, but that would seem the ultimate of non-portable).
At that point, the whole point of running a pluggable
*off-the-shelf* module in the same process context is defeated and you might
as well not use PAM at all.
Indeed. :-)
All this babble is all FUD. If you don't trust PAM modules, don't use them.
But that doesn't mean others should be barred from using them.
Hmmm.... Why is it that you (and other folks) seem to keep assuming
that I am (or anyone else desiring BSD Auth first and foremost is)
trying to prevent others from using PAM? I have never ever said that I
would refuse to allow anyoneto use PAM, and I've never ever tried to
even imply that others should never be able to use PAM with NetBSD
either. I'm quite happy to leave people to make their own choices and
to allow that PAM might be one of the choices they should be able to
make with NetBSD. I am of course trying to point out some of the
failings of PAM and I've been trying to show that it's not necessary for
any of things that people have been claiming so far that it's necessary
for. If I can convince anyone that they'd be happier without PAM then
I'm probably going to try to do so.

All I desire of NetBSD, and I desire it strongly enough to be very vocal
about it, is some way to ensure that I can continue to very easily build
a PAM-free system from NetBSD sources and that I can continue to also
very easily build a static-linked system which still uses nsswitch too.
If I can continue to do those things and also have BSD Auth
ready-integrated into NetBSD then I'm twice as happy. I myself don't
need BSD Auth for any custom authenticators since I'm quite capable of
integrating them directly with my own #ifdefs, but if BSD Auth is
available then I'll very happily use it instead, even if I still have to
write a custom authenticator program.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-12 23:50:03 UTC
Permalink
Post by Greg A. Woods
Hmmm.... Why is it that you (and other folks) seem to keep assuming
that I am (or anyone else desiring BSD Auth first and foremost is)
trying to prevent others from using PAM? I have never ever said that I
Well, those who are proponents of BSD Auth are basically preventing
people from using PAM by suggesting that PAM-on-top-of-BSD-Auth is
workable. In fact, it is not, since BSD Auth cannot do some of the
things PAM can do, period.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-13 01:37:40 UTC
Permalink
[ On Friday, September 12, 2003 at 16:50:03 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
Well, those who are proponents of BSD Auth are basically preventing
people from using PAM by suggesting that PAM-on-top-of-BSD-Auth is
workable.
Jason I'm sure that's the most bogus thing I've ever heard from you! I
can't believe you said it! Are you sure you're the same Jason Thorpe we
know from NetBSD circles behind that keyboard?

First off, how in heck can anything I, Peter, or anyone else have said
possibly ever prevent someone from using PAM!?!?!?!? Do we somehow have
far more power than we ever imagined possible? Are our mere words
somehow vexing everyone? Have our arguments really successfully won the
majority over and we're left now with even the core developers saying,
in private obviously, that PAM is right out? If so then "Hurray!", but
if not then what the heck are you talking about?

Secondly, how in the heck can saying that PAM via BSD Auth proxy is
possible ever even remotely be interpreted as "preventing people from
using PAM"!?!?! I'm saying _exactly_ the opposite! I'm saying anyone
_can_ use PAM; _and_ I'm showing how it is even feasible (for at least
the most sensible and most often expressed reasons) via a custom BSD
Auth authenticator proxy.

The only thing I've said that would not be acceptable to me for NetBSD
to implement is BSD Auth via PAM proxy. That would not only be a total
insult to the goals and ideals of BSD Auth, but it would also make it
impossible for anyone wanting a PAM-free system to make direct use of
BSD Auth authenticators (without first integrating BSD AUth directly by
themselves). It would also make it impossible to build a static-linked
NetBSD system (and especially one that used BSD Auth authenticators) (at
least without first going to the trouble of writing a fake dlopen() that
would simply hook in the already loaded PAM code and then hope its
authors didn't do something really stupid which caused it to fail when
their code was static linked (as some fans of dynamic linking are quite
prone to do)).
In fact, it is not, since BSD Auth cannot do some of the
things PAM can do, period.
Clearly BSD Auth cannot do some of the things PAM can do. However that
does not mean that PAM cannot be used by way of a BSD Auth proxy. It
also does not mean that PAM cannot be used independently of, but in
parallel with, BSD Auth by way of something like an extended nsswitch
API (and possibly via loadable nsswitch dispatch routines).

1. Peter (I think) said it most eloquently and more accurately before,
but the fact that BSD Auth cannot do some of the things PAM can do is
a tremendous, huge, _feature_ of BSD Auth, not a problem. If that's
not become obvious over all these _years_ of discussion, then I don't
know what has. None of us will ever even dare try to argue against
the fact that BSD Auth cannot do some of the things PAM can do.

2. Conversely BSD Auth can do some things that PAM will never be able to
do, such as delegation of authenticator privileges, protection of the
caller's address space and process context from un-wanted
interference by the authenticator (e.g. wandering pointer bugs and
worse), and avoidance of dynamic linking. I'm sure there are many
more such things, but hopefully you get the point.

3. Anything that any reasonable PAM code can do to its caller can be
done by proxy to the parent of a BSD Auth authenticator process
unless maybe the PAM thing does something like start a separate
thread and then expect to be able to run in that thread context until
the process exec()s or exits (which in my books is one of the least
reasonable things I can imagine any real PAM code ever doing, but
what the hell I've seen some really stupid things cooked up by
proporietary software vendors and I doubt I've seen the last of them)

Obviously proxies for PAM code are a lot more work to implement. I'm
not claiming otherwise. However they are clearly possible (for many, if
not most known examples of PAM code) and they make it possible to use
even third-party proprietary binary PAM code in a primarily BSD Auth
environment.

Then there's still the whole range of un-answered questions about just
who needs PAM and exactly why they need PAM for NetBSD and not some
equivalent alternative.

Nowhere yet have we seen anyone even attempt a scientific measure of the
real-world need for PAM amongst the current and the potential NetBSD
user-base.

People say they want AFS support and that they currently use PAM on
(pick-your-favourite-commercial-OS-or-linux) to make it work, but yet
AFS can quite easily be integrated into a system using BSD Auth with
only a slight modification to the existing mechanisms for registering
AFS credentials for a process group. Is PAM support really be necessary
to make it possible for NetBSD users now using PAM on other systems to
integrate AFS support into their NetBSD systems? What if NetBSD already
had at least the framework for AFS support by way of BSD Auth? How many
current and potential NetBSD users would use AFS support?

People say they want support for authenticators to designate template
accounts for users authenticated by a non-local mechanism that can't be
tied into nsswitch and that they currently use PAM on (pick-your-
favourite-commercial-OS-or-linux) to make it work, but yet Peter has
shown to the apparent satisfaction of at least one such requestor that
BSD Auth can quite easily implement such a scheme. Is PAM really
necessary to make it possible for NetBSD users now using PAM to do this
on other systems? What if NetBSD already had such support by way of BSD
Auth? How many current and potential NetBSD users would use template
account support?

People say they want support for proprietary, and possibly binary-only,
third-party PAM code. Obviouly only a PAM framework of some kind can
even begin to make this possible on NetBSD without reverse engineering
and re-implementing the third-party code. However every BSD Auth
proponent I'm aware of has allowed that it would be quite acceptable to
also include PAM support via something like a slightly enhanced nsswitch
API (assuming a proxy authenticator interface is not possible because
the vendor doesn't document what the PAM code does to its caller).
However the question here is how many current or potential NetBSD users
really need such support? Is it even possible to maintain full ABI
compatability on any existing platform with any existing native-OS PAM
framework? (Yes I know we have working syscall emulation for some other
operating systems, but what about native shared libraries the PAM code
might need clashing with NetBSD code the caller might need, and what
about the actual PAM ABI itself as well?) Are any PAM proponents able
to volunteer to work on such support and help get it integrated cleanly
into NetBSD such that it can work in parallel with BSD Auth?

Almost all of these questions have been asked several times already in
this most recent discussion, either directly or implicitly, by myself
and others, and yet outside the few people talking directly about their
own requirements there have not even been any projections made of
plausible answers, especially not to the quantifiable questions! Do we
need to re-ask over in netbsd-uers? Does nobody have even half a guess
to any one of these questions?
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-13 01:41:36 UTC
Permalink
Post by Greg A. Woods
First off, how in heck can anything I, Peter, or anyone else have said
possibly ever prevent someone from using PAM!?!?!?!? Do we somehow have
Ok, my wording was poor. My point is, if the people who want BSD Auth
"win", then people who want to use PAM "lose", because PAM cannot be
implemented using BSD Auth as the back-end.

-- Jason R. Thorpe <***@wasabisystems.com>
Greywolf
2003-09-13 02:37:57 UTC
Permalink
Thus spake Jason Thorpe ("JT> ") sometime Today...

JT> On Friday, September 12, 2003, at 06:37 PM, Greg A. Woods wrote:
JT>
JT> > First off, how in heck can anything I, Peter, or anyone else have said
JT> > possibly ever prevent someone from using PAM!?!?!?!? Do we somehow
JT> > have
JT>
JT> Ok, my wording was poor. My point is, if the people who want BSD Auth
JT> "win", then people who want to use PAM "lose", because PAM cannot be
JT> implemented using BSD Auth as the back-end.

I think the concept is being missed. What is desired is not that either
side "win", as in "if PAM goes in, then BSD Auth doesn't" (or vice versa),
but rather that there is a choice as to which the person doing the
administration of the system in question might use.

If we can stop viewing this as a one-vs.-the-other, or a win-lose situation,
we might get somewhere. As long as it IS a one-vs.-the-other situation,
nobody is going to come out of it truly happy.

--*greywolf;
--
NetBSD: May the Source be with you.
Jason Thorpe
2003-09-13 06:55:24 UTC
Permalink
Post by Greywolf
I think the concept is being missed. What is desired is not that either
side "win", as in "if PAM goes in, then BSD Auth doesn't" (or vice versa),
but rather that there is a choice as to which the person doing the
administration of the system in question might use.
Unfortunately, for any one of them to be useful requires a level of
integration which generally precludes using the other.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-13 17:09:55 UTC
Permalink
[ On Friday, September 12, 2003 at 23:55:24 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
Unfortunately, for any one of them to be useful requires a level of
integration which generally precludes using the other.
"Show me."
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greg A. Woods
2003-09-13 06:09:50 UTC
Permalink
[ On Saturday, September 13, 2003 at 14:40:59 (+0900), Jun-ichiro itojun Hagino wrote: ]
Subject: Re: BSD auth for NetBSD
we could introduce PAM and BSD auth into the system independently,
and let apps chose which to use (or build time option USE_PAM/BSDAUTH).
A build-time option to select between the two would be good regardless.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greg A. Woods
2003-09-13 04:44:53 UTC
Permalink
[ On Friday, September 12, 2003 at 18:41:36 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
Ok, my wording was poor. My point is, if the people who want BSD Auth
"win", then people who want to use PAM "lose", because PAM cannot be
implemented using BSD Auth as the back-end.
All that's been asked of PAM to date certainly can be implemented by a
BSD Auth proxy -- you just have to think a little more outside the box!

But OK, anyways, you've apparently missed seeing the proposal to make it
possible for both to live side by side using a slightly enhanced
nsswitch-like way of dispatching authentication requests to a run-time
configurable authentication service.

Regardless of whether the current nsswitch survives or is replaced by
the ISC IRS code or something else entirely, and regardless of whether
or not anyone actually ever uses BSD Auth and PAM together on the same
system, it still makes a whole lot of sense to have some form of
nsswitch-like way of dispatching authentication attempts so that base OS
applications such as login, ftpd, etc., can all make use of a common API
when making authentication requests. Having such a scheme is a big boon
even if both BSD Auth and PAM go off into their corners and rot away
forever since even just having a standard way of hooking in new library
code to do authentication is a major win (just as nsswitch today is
already a major win for providing run-time configurable back-ends for
getpw*). Presumably this new API would be controlled through login.conf
or some new config file, not nsswitch.conf, though I guess it really
doesn't matter that much. The point is assuming this API is generic
and/or flexible enough that it can drive both BSD Auth and PAM then the
sky's the limit and I think everyone will be able to get the most out of
NetBSD.

BSD Auth is apparently ready to go now, but there's nothing stopping PAM
from coming along any time later, regardless of whether or not we have
the intermediate API right away, and regardless of whether or not anyone
tries to actually make a PAM proxy the way I've described. There's just
no valid reason not to immediately integrate BSD Auth since it will
immediately make life easier for those who can use it. Nobody will lose
anything though since doing so isn't an impediment to designing this new
API and using it to also hook directly PAM into the system.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-13 07:01:21 UTC
Permalink
Post by Greg A. Woods
Regardless of whether the current nsswitch survives or is replaced by
the ISC IRS code or something else entirely, and regardless of whether
I think there's little chance of nsswitch being replaced by irs.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-13 17:12:53 UTC
Permalink
[ On Saturday, September 13, 2003 at 00:01:21 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
I think there's little chance of nsswitch being replaced by irs.
Although I'm no big fan of supporting threaded code it would seem to me
that something has to be done to "fix" nsswitch and I'm on the side of
using something that already exists if it is well designed, even if it
means changing internal system APIs a bit. I don't know if IRS meets
those criteria, but if I'm not mistaken some people seem to think it does.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-13 17:18:59 UTC
Permalink
Post by Greg A. Woods
[ On Saturday, September 13, 2003 at 00:01:21 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
I think there's little chance of nsswitch being replaced by irs.
Although I'm no big fan of supporting threaded code it would seem to me
that something has to be done to "fix" nsswitch and I'm on the side of
using something that already exists if it is well designed, even if it
means changing internal system APIs a bit. I don't know if IRS meets
those criteria, but if I'm not mistaken some people seem to think it does.
The changes to make nsswitch thread-safe have already been made by a
3rd party, and will be integrated into NetBSD in the near future.

irs, while it does technically exist, requires a significant amount of
effort even to integrate into the NetBSD system, much more effort than
is required to apply the thread-safety fixes to nsswitch. Even then,
irs will not provide all of the functionality that our current nsswitch
provides, and that is even before nsswitch gets support for dynamic
loading of modules (changes that implement this are also available from
a 3rd party). irs would require a major overhaul to support dynamic
loading of modules.

Furthermore, nsswitch is far more common in the Unix world than irs,
and so nsswitch buys us a compatiblity-with-other-systems checkbox that
irs does not. (What OSs even ship with irs these days? BSD/OS? I
can't think of any other OS that does, and BSD/OS is about to go the
way of the dodo.)

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-14 18:53:44 UTC
Permalink
[ On Saturday, September 13, 2003 at 10:18:59 (-0700), Jason Thorpe wrote: ]
Subject: Re: nsswitch vs ISC IRS
The changes to make nsswitch thread-safe have already been made by a
3rd party, and will be integrated into NetBSD in the near future.
Ah, this is good news (and news to me! :-)
irs, while it does technically exist, requires a significant amount of
effort even to integrate into the NetBSD system, much more effort than
is required to apply the thread-safety fixes to nsswitch.
Having read the code for both I can very much appreciate that.

I'm not entirely happy with the internals of nsswitch, and though in
some ways IRS looks to have a cleaner start and a more elegant
implementation I'm not in a position to evaluate all of the related
issues. It would help I suppose if the wayt the getpw*() routines use
nsdispatch() were documented. The nsdispatch(3) manual page itself is
all fine and good, but none of the magic of cb_data is documented for
any of the primary users of nsdispatch() such as getpw*() or gethost*(),
not even with internal comments so far as I can find. Hopefully some
better documentation will come along with the new thread-safe version.
Even then,
irs will not provide all of the functionality that our current nsswitch
provides
If I'm thinking of what you're thinking of then that's true enough
(though I'm not sure it's important enough functionality to worry about
keeping, but that's a separate issue).

The issue perhaps then becomes deciding which of IRS v.s. resolver
hacking is more effort.

I would very much like to see at least the BIND-8 resolver code imported
to NetBSD A.S.A.P., and I can very much see how this would be on hell
of a lot easier to do if NetBSD simply used IRS across the board.

I know it doesn't make any sense to import IRS and to front it with
nsswitch -- that's a one-way-street to confusion for everyone for sure.

However porting BIND-8 to NetBSD w/nsswitch seems like it will be a lot
of work -- work that will not be easy to automate for any new releases
of the BIND-8 resolver code either (though perhaps we're nearing the end
of any major shakeups in their internals, so automation via patch may be
sufficient).

Alternately moving NetBSD to the BIND-9 lwres would be fun! ;-)
and that is even before nsswitch gets support for dynamic
loading of modules (changes that implement this are also available from
a 3rd party)
irs would require a major overhaul to support dynamic
loading of modules.
I'm not so sure about that, but I'm not one who would go about trying to
do such things either. :-)
Furthermore, nsswitch is far more common in the Unix world than irs,
and so nsswitch buys us a compatiblity-with-other-systems checkbox that
irs does not. (What OSs even ship with irs these days? BSD/OS? I
can't think of any other OS that does, and BSD/OS is about to go the
way of the dodo.)
I'm not sure who needs that kind of compatability.

You must be talking about user-level compatability because although I've
not seen Sun's internals, I can't imagine that they look even remotely
like NetBSD's given what I've seen from the outside and what I've read
in texts describing Sun's implementation.

NetBSD's nsswitch is already incompatible enough with its roots at the
user level to cause at least some minor confusion for folks I know who
are experts with _using_ the likes of the Solaris implementation.

I.e. I just don't think compatability of some sort is a useful enough
argument to bother with.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jun-ichiro itojun Hagino
2003-09-13 05:40:59 UTC
Permalink
Post by Jason Thorpe
Post by Greg A. Woods
First off, how in heck can anything I, Peter, or anyone else have said
possibly ever prevent someone from using PAM!?!?!?!? Do we somehow have
Ok, my wording was poor. My point is, if the people who want BSD Auth
"win", then people who want to use PAM "lose", because PAM cannot be
implemented using BSD Auth as the back-end.
we could introduce PAM and BSD auth into the system independently,
and let apps chose which to use (or build time option USE_PAM/BSDAUTH).

itojun
Roland Dowdeswell
2003-09-13 06:36:55 UTC
Permalink
On 1063431659 seconds since the Beginning of the UNIX epoch
we could introduce PAM and BSD auth into the system independently,
and let apps chose which to use (or build time option USE_PAM/BSDAUTH).
A lot of the main consumers of the client side API are in basesrc.
I think that to some degree this is going overboard---we need to
decide on what API that authentication clients are going to use
and stick with it rather than maintaining both. As I see it we
have a choice between PAM which is used in Solaris, FreeBSD, Linux,
etc, or BSD Auth which is used in OpenBSD and BSDI. BSDI is
officially unsupported [soon]. Given the size of OpenBSD's userbase,
if we decide to use BSD Auth we will continue to be in the unfortunate
position that hardly anything in pkgsrc will support our authentication
mechanisms. This appears on first inspection to be a losing
proposition.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Jason Thorpe
2003-09-13 07:09:26 UTC
Permalink
Post by Roland Dowdeswell
A lot of the main consumers of the client side API are in basesrc.
I think that to some degree this is going overboard---we need to
decide on what API that authentication clients are going to use
and stick with it rather than maintaining both. As I see it we
have a choice between PAM which is used in Solaris, FreeBSD, Linux,
etc, or BSD Auth which is used in OpenBSD and BSDI. BSDI is
officially unsupported [soon]. Given the size of OpenBSD's userbase,
if we decide to use BSD Auth we will continue to be in the unfortunate
position that hardly anything in pkgsrc will support our authentication
mechanisms. This appears on first inspection to be a losing
proposition.
I agree completely. PAM is widely adopted. BSD Auth is something that
is really on the fringes.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-13 17:08:54 UTC
Permalink
[ On Saturday, September 13, 2003 at 02:36:55 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
A lot of the main consumers of the client side API are in basesrc.
I think that to some degree this is going overboard---we need to
decide on what API that authentication clients are going to use
and stick with it rather than maintaining both.
You might think it's "overboard", but as someone who's seen these things
come and go I can assure you that having the ability to put common
wrapper APIs around things that do authentication actually makes
maintaining the base OS a lot easier.

This was already done for getpw* and hostnames, and it only makes sense
to do it again for the one remaining "A" in the "A&A" problem area:
Authentication.
As I see it we
have a choice between PAM which is used in Solaris, FreeBSD, Linux,
etc, or BSD Auth which is used in OpenBSD and BSDI. BSDI is
officially unsupported [soon]. Given the size of OpenBSD's userbase,
if we decide to use BSD Auth we will continue to be in the unfortunate
position that hardly anything in pkgsrc will support our authentication
mechanisms. This appears on first inspection to be a losing
proposition.
I don't wish to turn this into a personal attack but your logic really
does seem to me to border on that of the worst unthinking sale droid.
Hopefully such market-_focused_ reasoning continues to be lowest and
least important of all NetBSD's overall goals.

I'm waiting now to see what you might say now that you've hopefully seen
through the veneer of your "first inspection"! ;-)

I'm still stumbling over the idea that we would really ever care whether
anything third party supports _our_ authentication mechanisms. Of
course I may be thinking of different things than you're thinking of.

To me it really doesn't matter one hoot if anyone else but NetBSD and
OpenBSD users write new authenticators for BSD Auth. Those are so easy
to write that they really don't need third party support. All we need
from third parties are command-line applications or libraries that can
interface with whatever tools might be used to do

As for things that make authentication requests, well there's been such
a cry for a standard API for making authentication requests in certain
application areas that major third-party software groups have already
collaborated to create one: RFC 2222 (SASL).

Authentication APIs are really quite easy in theory. You simply need
some way to ask some authoritative source whether the entity being
authenticated is who he or she or what says he or she or it is. This
means taking an identity identifier, and possibly a secret, from the
entity and passing it to the authenticator, possibly along with an
indication of how the authenticator can interact with the entity for
further challenges, and then wait for a binary "yay" or "nay" answer
from the authenticator. (There have been authenticators which return a
"maybe" answer too which might contain a pointer to some qualifier, such
as "If authenticator B also says "yes", though in theory that can all be
hidden from the application servers by having A invoke B directly, or
with a wrapper that runs in a loop until it gets a firm answer or runs
out of options.)

So the point I'm trying to make is that worrying over which framework
has third party support without knowing all the details of how important
such support might be is pointless.

Now while BSD Auth may be sufficient for NetBSD (despite what Todd tried
to say but said so obtusely), there are still good reasons to "hide" the
actual framework used to implement authenticators behind an API in libc
that can be made run-time configurable to support multiple frameworks.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-13 17:27:31 UTC
Permalink
On 1063472934 seconds since the Beginning of the UNIX epoch
Post by Greg A. Woods
You might think it's "overboard", but as someone who's seen these things
come and go I can assure you that having the ability to put common
wrapper APIs around things that do authentication actually makes
maintaining the base OS a lot easier.
That is what PAM and BSD Auth are, wrapper APIs around things that
do authentication. I was suggesting that it is going overboard to
put a wrapper around two wrappers which will surely end up having
the compromises of both systems.
Post by Greg A. Woods
I don't wish to turn this into a personal attack but your logic really
does seem to me to border on that of the worst unthinking sale droid.
Hopefully such market-_focused_ reasoning continues to be lowest and
least important of all NetBSD's overall goals.
I do not see how wanting to be able to use 3rd party applications
is ``market-_focused_ reasoning''. Maybe you do not feel that it
is necessary to use anything that is not in basesrc, but many of
the rest of us actually appreciate the fact that NetBSD can compile
and run applications that were written on other UNIX systems.
Being able to do this follows from making a series of decisions
about adhering to standards that are commonly accepted by the UNIX
community.

Do you think that providing POSIX compatibility is ``market-_focused_
reasoning''? Maybe it is... But I am quite glad that we have
decided to be `sale droid'-ish on that issue.
Post by Greg A. Woods
I'm waiting now to see what you might say now that you've hopefully seen
through the veneer of your "first inspection"! ;-)
I'm still stumbling over the idea that we would really ever care whether
anything third party supports _our_ authentication mechanisms. Of
course I may be thinking of different things than you're thinking of.
Greg, when you have provided BSD Auth client level support to all
of the things in pkgsrc that support PAM, e.g. gdm, kdm, xlock,
xscreensaver, and so on, then please by all means tell us how little
you care about 3rd party support for _our_ authentication mechanisms.
I have little desire to do that, and apparently you do not either
since I haven't seen any patches from you providing said support.

One of the big reasons to go with PAM or BSD Auth is to get NetBSD
out of the rather annoying situation that 3rd party applications
do not authenticate in the same way as the base operating system.
Post by Greg A. Woods
To me it really doesn't matter one hoot if anyone else but NetBSD and
OpenBSD users write new authenticators for BSD Auth. Those are so easy
to write that they really don't need third party support. All we need
from third parties are command-line applications or libraries that can
interface with whatever tools might be used to do
Yes, I probably don't care either. What I care about is the _clients_
will acutally authenticate in the same way as login(1).
Post by Greg A. Woods
As for things that make authentication requests, well there's been such
a cry for a standard API for making authentication requests in certain
application areas that major third-party software groups have already
collaborated to create one: RFC 2222 (SASL).
Uh, SASL and PAM solve entirely different problems.
Post by Greg A. Woods
So the point I'm trying to make is that worrying over which framework
has third party support without knowing all the details of how important
such support might be is pointless.
As I said above: put up the code for all the apps in pkgsrc and
get back to me.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Greg A. Woods
2003-09-13 18:18:12 UTC
Permalink
[ On Saturday, September 13, 2003 at 13:27:31 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
That is what PAM and BSD Auth are, wrapper APIs around things that
do authentication. I was suggesting that it is going overboard to
put a wrapper around two wrappers which will surely end up having
the compromises of both systems.
No, that's not really true. PAM and BSD Auth are authentication
frameworks. I'm talking only about a "shim" API that hides the
particular flavour of framework from applications.
I do not see how wanting to be able to use 3rd party applications
is ``market-_focused_ reasoning''.
The point is that choosing an authentication framework solely based on
its market share does not jive at all with the expressed common goals of
NetBSD, especially when it's not the technicaly superior framework.
Maybe you do not feel that it
is necessary to use anything that is not in basesrc, but many of
the rest of us actually appreciate the fact that NetBSD can compile
and run applications that were written on other UNIX systems.
Indeed, but as I pointed out most of those problems are already solved
for the vast majority of applications without having to be compatible
with any particular authentication framework.
Do you think that providing POSIX compatibility is ``market-_focused_
reasoning''? Maybe it is... But I am quite glad that we have
decided to be `sale droid'-ish on that issue.
While POSIX compatability is at a whole different level, the point is
that choosing anything solely based on market share, especially for any
open source system, is not productive.

If there were an agreed upon, non-vendor-driven, authentication API that
met all the common needs and didn't force irrelevant implementation
decisions on users then it would be a good thing to implement
_compatability_ to that API just as POSIX _compatability_ is good thing.
Greg, when you have provided BSD Auth client level support to all
of the things in pkgsrc that support PAM, e.g. gdm, kdm, xlock,
xscreensaver, and so on, then please by all means tell us how little
you care about 3rd party support for _our_ authentication mechanisms.
I have little desire to do that, and apparently you do not either
since I haven't seen any patches from you providing said support.
All those things that need specific support for either PAM or BSD Auth
or whatever cool new thing comes along next are equally broken by
design.

Step one is to implement an API at the level of nsswitch that hides the
authentication framework.

At that point it becomes irrelevant which framework you choose to use on
your system.
One of the big reasons to go with PAM or BSD Auth is to get NetBSD
out of the rather annoying situation that 3rd party applications
do not authenticate in the same way as the base operating system.
Well, actually, no, that's not any real reason at all.

I think you're not looking at how authentication fits into the system
and how authentication is used in production environments properly. All
the tools in pkgsrc already work perfectly fine with the existing getpw*
support in the native OS.

The real reason to integrate both PAM and BSD Auth is to make it
possible to have run-time configurable and run-time extensible
authentication frameworks that themselves have run-time configurable and
extensible authenticators.
Yes, I probably don't care either. What I care about is the _clients_
will acutally authenticate in the same way as login(1).
Me too, which is why step one is to implement a runtime configurable and
extensible authentication API that can drive any framework.
Uh, SASL and PAM solve entirely different problems.
Really? :-)
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Todd Vierling
2003-09-13 18:24:21 UTC
Permalink
On Sat, 13 Sep 2003, Greg A. Woods wrote:

: The point is that choosing an authentication framework solely based on
: its market share does not jive at all with the expressed common goals of
: NetBSD, especially when it's not the technicaly superior framework.

Certainly you're not saying that BSD Auth is "technicaly superior" to PAM.

Can I have a hit from that crackpipe? I need something to help me wake up
today.
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Greg A. Woods
2003-09-13 20:19:57 UTC
Permalink
[ On Saturday, September 13, 2003 at 14:24:21 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
: The point is that choosing an authentication framework solely based on
: its market share does not jive at all with the expressed common goals of
: NetBSD, especially when it's not the technicaly superior framework.
Certainly you're not saying that BSD Auth is "technicaly superior" to PAM.
Yes I certainly do feel that technically BSD Auth _is_ far superior to
PAM -- especially in the context of NetBSD.

The whole idea for PAM comes directly from environments that have goals
and requirements which are totally antithetic of open source systems and
unfortunately the resulting design of PAM places constraints on
implementations that are irrelevant and/or contrary to the goals and
requirements of open source systems and open source users, including
those publicly stated for NetBSD.

If you have technical criticisms of BSD Auth which are more
sophisticated than the overly-repeated lame and meaningless excuse that
BSD Auth authenticators can't interact directly and freely with the
caller's address space and process context then please let's hear them!

However if all you can mumble about PAM boils down to the sole fact that
it's design allows authenticators free reign over the caller's address
space and process context then please forget I asked because the reason
I want BSD Auth (and I'm sure I'm not alone on this) is explicitly to
move those authenticators out into their own process space and to be
much more picky about how they can communicate and even what identity
they might run under. No amount of using that as your excuse to justify
PAM will ever fly, just as the idea of using BSD Auth authenticators
from a PAM proxy module will never fly with anyone who primarily wants
to use BSD Auth as putting PAM in the middle not only complicates
something that would otherwise be very simple but it flies in the face
of the goals of BSD Auth and is an insult to its inventors.

Technically PAM is a wide open mine field giving full and unfettered
access to the caller.

Technically PAM does not even allow authenticator code in the module to
run as a different UID (at least not in any meaningfully secure way).

If you think the presence of those problems in PAM allows it to be
technically superior to BSD Auth in any way then you're welcome to your
opinion but please don't expect me to follow your apparent beliefs.

You say you don't like PAM but yet you've been effectively appologizing
for its failings and helping prop it up.

I clearly don't like PAM and I'm not going to stop fighting against its
scourge, but I'm also still not going to stand directly in the way of
anyone who truly thinks they need to use it (though I will try to point
them to alternatives), and I still won't stand directly in the way of
anyone who wants to find some way to glue it into the base NetBSD source
tree, just so long as it never becomes an absolute requirement for
NetBSD users (at least not at the source level -- I could care less
about the default binary distributions). I.e. do not confuse my
criticisms of PAM with a refusal to allow it to exist. I know it exists
and I'm not in a position to either prevent people from using, nor am I
in a position to provide, on my own, a complete ready-to-use alternative
for those people who think they need it. All I've ever asked is that it
not be thrust down my throat.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jun-ichiro itojun Hagino
2003-09-13 23:07:51 UTC
Permalink
one of the benefit of BSD auth (which has not been mentioned here)
is that it can reduce the number of setuid root programs directly
invoked from the user. programs that needs authentication just need
to be setgid "auth" (to access authentication programs under
/usr/libexec/auth). authentication logic
(i.e. /usr/libexec/auth/login_passwd) works in separate address space,
so there's less chance for bad guys to trick them.
with PAM, setuid programs(like /usr/bin/login) needs to stay setuid
root, and they have to introduce dlopen() which can open up a can
of worms.

itojun


itojun[starfruit:~] uname -a
NetBSD starfruit.itojun.org 1.6Z NetBSD 1.6Z (STARFRUIT) #461: Fri Sep 12 20:23:17 JST 2003 ***@starfruit.itojun.org:/home/itojun/NetBSD/src/sys/arch/i386/compile/STARFRUIT i386
itojun[starfruit:~] ls -l `find /usr/bin -perm 4555 -print` `find /usr/sbin -perm 4555 -print`
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/at
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atq
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atrm
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/batch
-r-sr-xr-x 3 root wheel 19112 Sep 6 21:30 /usr/bin/chfn
-r-sr-xr-x 3 root wheel 19112 Sep 6 21:30 /usr/bin/chpass
-r-sr-xr-x 3 root wheel 19112 Sep 6 21:30 /usr/bin/chsh
-r-sr-xr-x 1 root wheel 24048 Sep 6 21:30 /usr/bin/crontab
-r-sr-xr-x 1 uucp wheel 119776 Sep 6 21:21 /usr/bin/cu
-r-sr-xr-x 3 root wheel 16832 Sep 6 21:31 /usr/bin/kpasswd
-r-sr-xr-x 1 root wheel 27296 Sep 6 21:30 /usr/bin/login
-r-sr-xr-x 3 root wheel 16832 Sep 6 21:31 /usr/bin/passwd
-r-sr-xr-x 1 root wheel 12108 Sep 6 21:31 /usr/bin/rlogin
-r-sr-xr-x 1 root wheel 4784 Sep 6 21:32 /usr/bin/skeyinfo
-r-sr-xr-x 1 root wheel 11532 Sep 10 20:09 /usr/bin/skeyinit
-r-sr-xr-x 1 root wheel 18444 Sep 6 21:31 /usr/bin/su
-r-sr-xr-x 1 uucp wheel 85852 Sep 6 21:21 /usr/bin/uucp
-r-sr-xr-x 1 uucp wheel 35580 Sep 6 21:21 /usr/bin/uuname
-r-sr-xr-x 1 uucp wheel 93984 Sep 6 21:21 /usr/bin/uustat
-r-sr-xr-x 1 uucp wheel 85804 Sep 6 21:21 /usr/bin/uux
-r-sr-xr-x 3 root wheel 16832 Sep 6 21:31 /usr/bin/yppasswd
-r-sr-xr-x 1 root wheel 15336 Sep 6 21:35 /usr/sbin/mrinfo
-r-sr-xr-x 1 root wheel 26504 Sep 6 21:46 /usr/sbin/mtrace
-r-sr-xr-x 1 root wheel 185432 Sep 6 21:36 /usr/sbin/pppd
-r-sr-xr-x 1 root wheel 8812 Sep 6 21:36 /usr/sbin/sliplogin
-r-sr-xr-x 1 root wheel 14912 Sep 6 21:36 /usr/sbin/timedc
-r-sr-xr-x 1 root wheel 19436 Sep 6 21:36 /usr/sbin/traceroute
-r-sr-xr-x 1 root wheel 18288 Sep 6 21:37 /usr/sbin/traceroute6
itojun[starfruit:~] ls -l `find /usr/bin -perm 2555 -print` `find /usr/sbin -perm 2555 -print`
-r-xr-sr-x 1 root kmem 18336 Sep 6 21:30 /usr/bin/fstat
-r-xr-sr-x 1 root auth 7912 Sep 10 19:40 /usr/bin/lock
-r-xr-sr-x 1 root kmem 5996 Sep 6 21:31 /usr/bin/modstat
-r-xr-sr-x 1 root kmem 110200 Sep 12 19:42 /usr/bin/netstat
-r-xr-sr-x 1 root kmem 34940 Sep 6 21:31 /usr/bin/pmap
-r-xr-sr-x 2 root kmem 83752 Sep 6 21:31 /usr/bin/sysstat
-r-xr-sr-x 2 root kmem 83752 Sep 6 21:31 /usr/bin/systat
-r-xr-sr-x 1 root kmem 31260 Sep 6 21:32 /usr/bin/vmstat
-r-xr-sr-x 1 root tty 11528 Sep 6 21:32 /usr/bin/wall
-r-xr-sr-x 1 root tty 10728 Sep 6 21:32 /usr/bin/write
-r-xr-sr-x 1 root daemon 27840 Sep 6 21:35 /usr/sbin/lpc
-r-xr-sr-x 1 root maildrop 75824 Sep 6 21:26 /usr/sbin/postdrop
-r-xr-sr-x 1 root maildrop 67200 Sep 6 21:26 /usr/sbin/postqueue
-r-xr-sr-x 1 root kmem 18348 Sep 6 21:36 /usr/sbin/pstat
-r-xr-sr-x 1 root kmem 7696 Sep 6 21:36 /usr/sbin/slstats
-r-xr-sr-x 1 root kmem 10120 Sep 6 21:36 /usr/sbin/trpt
-r-xr-sr-x 1 root kmem 10056 Sep 6 21:36 /usr/sbin/trsp



itojun[tapioca:~] uname -a
OpenBSD tapioca.itojun.org 3.4 GENERIC#79 macppc
itojun[tapioca:~] ls -l `find /usr/bin -perm 4555 -print` `find /usr/sbin -perm 4555 -print`
-r-sr-xr-x 3 root bin 21576 Sep 12 20:20 /usr/bin/chfn
-r-sr-xr-x 3 root bin 21576 Sep 12 20:20 /usr/bin/chpass
-r-sr-xr-x 3 root bin 21576 Sep 12 20:20 /usr/bin/chsh
-r-sr-xr-x 1 root bin 21572 Sep 12 20:20 /usr/bin/passwd
-r-sr-xr-x 1 root bin 17316 Apr 14 2002 /usr/bin/rlogin
-r-sr-xr-x 1 root bin 8436 Sep 12 20:20 /usr/bin/rsh
-r-sr-xr-x 1 root bin 11684 Sep 12 20:20 /usr/bin/su
-r-sr-xr-x 1 root bin 91276 Sep 12 20:20 /usr/bin/sudo
-r-sr-xr-x 1 root bin 192492 Sep 12 20:21 /usr/sbin/timedc
-r-sr-xr-x 1 root bin 198980 Sep 12 20:21 /usr/sbin/traceroute
-r-sr-xr-x 1 root bin 196764 Sep 12 20:21 /usr/sbin/traceroute6
itojun[tapioca:~] ls -l `find /usr/bin -perm 2555 -print` `find /usr/sbin -perm 2555 -print`
-r-xr-sr-x 4 root crontab 31796 Sep 12 20:20 /usr/bin/at
-r-xr-sr-x 4 root crontab 31796 Sep 12 20:20 /usr/bin/atq
-r-xr-sr-x 4 root crontab 31796 Sep 12 20:20 /usr/bin/atrm
-r-xr-sr-x 4 root crontab 31796 Sep 12 20:20 /usr/bin/batch
-r-xr-sr-x 1 root crontab 29512 Sep 12 20:20 /usr/bin/crontab
-r-xr-sr-x 1 root kmem 17672 Sep 12 20:20 /usr/bin/fstat
-r-xr-sr-x 1 root auth 7100 Sep 12 20:20 /usr/bin/lock
-r-xr-sr-x 1 root daemon 21872 Sep 12 20:21 /usr/bin/lpq
-r-xr-sr-x 1 root _lkm 5652 Sep 12 20:20 /usr/bin/modstat
-r-xr-sr-x 1 root kmem 117756 Sep 12 20:20 /usr/bin/netstat
-r-xr-sr-x 1 root auth 7580 Sep 12 20:20 /usr/bin/skeyaudit
-r-xr-sr-x 1 root auth 5072 Sep 12 20:20 /usr/bin/skeyinfo
-r-xr-sr-x 1 root auth 15640 Sep 12 20:20 /usr/bin/skeyinit
-r-xr-sr-x 1 root _sshagnt 55656 Sep 12 20:20 /usr/bin/ssh-agent
-r-xr-sr-x 1 root kmem 55316 Sep 12 20:20 /usr/bin/systat
-r-xr-sr-x 1 root kmem 31396 Sep 12 20:20 /usr/bin/vmstat
-r-xr-sr-x 1 root tty 10868 Sep 12 20:20 /usr/bin/wall
-r-xr-sr-x 1 root tty 8608 Sep 12 20:20 /usr/bin/write
-r-xr-sr-x 1 root daemon 33220 Sep 12 20:21 /usr/sbin/lpc
-r-xr-sr-x 1 root kmem 17484 Sep 12 20:21 /usr/sbin/pstat
-r-xr-sr-x 1 root kmem 9560 Apr 14 2002 /usr/sbin/trsp
Noriyuki Soda
2003-09-14 00:08:10 UTC
Permalink
Post by Jun-ichiro itojun Hagino
On Sun, 14 Sep 2003 08:07:51 +0900 (JST),
one of the benefit of BSD auth (which has not been mentioned here)
That's already mentioned. See the discussion about screensavers.
Post by Jun-ichiro itojun Hagino
with PAM, setuid programs(like /usr/bin/login) needs to stay setuid
root, and they have to introduce dlopen() which can open up a can
of worms.
As already mentioned by me, refering /usr/bin/login as an example
for this is just wrong.
/usr/bin/login doesn't have to be setuid root even with PAM,
it if doesn't need the traditional feature that users can
change their login-user from their login-shell.
The reason that /usr/bin/login has be to setuid root is not
only because it needs authentication, but also because it
needs authorization (i.e. it needs setuid(), setgid() and
setgroups()) from an unprivileged state (i.e. from login-shell).

If /usr/bin/login doesn't need to change the login-user from a
login-shell, it doesn't need the setuid bit at all, because it is
usually invoked with root privilege (except the login-shell case).
Post by Jun-ichiro itojun Hagino
itojun[starfruit:~] ls -l `find /usr/bin -perm 4555 -print` `find /usr/sbin -perm 4555 -print`
Your example isn't quite right.
Most of your examples (including /usr/bin/login) aren't related to the
PAM vs BSD auth difference.
Post by Jun-ichiro itojun Hagino
is that it can reduce the number of setuid root programs directly
invoked from the user.
And as I alreday wrote, this is the point where I think BSD auth
made a mistake. Actually there is only very few number of such programs
except screensavers. And the problem of screensavers can be fixed even
with PAM easily.
So, actual number of setuid programs may rather increases with BSD auth,
due to its authentication modules.
--
soda
Greg A. Woods
2003-09-14 18:11:08 UTC
Permalink
[ On Sunday, September 14, 2003 at 09:08:10 (+0900), Noriyuki Soda wrote: ]
Subject: Re: BSD auth for NetBSD
And as I alreday wrote, this is the point where I think BSD auth
made a mistake. Actually there is only very few number of such programs
except screensavers. And the problem of screensavers can be fixed even
with PAM easily.
Well I don't know about all screensavers, nor do I know about all PAM
implementations, but I do know that pkgsrc/x11/xlockmore with PAM
support will want to run with enough privileges to read the shadow
password file (spwd.db, /etc/shadow, whatever) so that the PAM code can
read the encrypted secret, thus meaning any bug in a PAM-ified xlockmore
can lead directly to rogue code reading the whole shadow passsword
database. The fact is such bugs have been frequent and exploitable in
xlockmore, partly due to the fact that a full implementation of it pulls
in more third party library code than almost any other single X11
application known to man. Think about it. The PAM code must somehow
directly read the shadow password database in order to access the
encrypted secrets. This means that for a time there will be an open
file descriptor for that database. At this point it's irrelevant
whether or not the PAM code has to run as root or just as whatever
unique group-ID one might think it is safe to use to access the shadow
password database.

The fact is it is _never_ safe to allow anything but UID==0 to access
the shadow password database, at least not so long as the (even)
encrypted secret for the superuser resided in that same database.
So, actual number of setuid programs may rather increases with BSD auth,
due to its authentication modules.
You are mistaken. BSD Auth is not mistaken.

BSD Auth really does reduce the number of setuid programs which may be,
and/or are commonly, invoked directly by users.

Note the very important caveat: "invoked _directly_ by users".

The problems for screensavers and everything else which starts its life
running as a normal non-privileged identity, is also easily be solved
with BSD Auth without ever giving the likes of xlockmore process direct
access to the shadow password database (just as well as Crys SASL solves
the same problem for similar non-privileged applications as well). With
BSD Auth (as with Cyrus SASL and saslauthd), the process with access to
the shadow password database is completely isolated from the process
requesting authentication services and no rogue or exploit code in
something like xlockmore can ever do anything more than what any idiot
at a "login:" prompt can do.

So, anyone who claims PAM is in some way technically superior to BSD
Auth is really right off their rocker! No authentication code which
runs in the context of the caller can ever be considered "technically
superior" to BSD Auth, and that includes good old getspw*() and crypt().
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-14 00:21:43 UTC
Permalink
On 1063494471 seconds since the Beginning of the UNIX epoch
Post by Jun-ichiro itojun Hagino
one of the benefit of BSD auth (which has not been mentioned here)
is that it can reduce the number of setuid root programs directly
invoked from the user. programs that needs authentication just need
to be setgid "auth" (to access authentication programs under
/usr/libexec/auth). authentication logic
(i.e. /usr/libexec/auth/login_passwd) works in separate address space,
so there's less chance for bad guys to trick them.
with PAM, setuid programs(like /usr/bin/login) needs to stay setuid
root, and they have to introduce dlopen() which can open up a can
of worms.
There is nothing about PAM which limits you to being setuid root.
You can exec helpers or talk to local domain sockets either from
the modules or from the main framework. I believe that LinuxPAM
already does this---or at least it documents that it does.

Also, programs like login(1) or su(1) are not good examples because
they must be setuid root anyway to change the uid upon successful
authentication.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Noriyuki Soda
2003-09-14 00:39:17 UTC
Permalink
Post by Roland Dowdeswell
On Sat, 13 Sep 2003 20:21:43 -0400,
Also, programs like login(1) or su(1) are not good examples because
they must be setuid root anyway to change the uid upon successful
authentication.
Well, login(1) isn't setuid root on OpenBSD.
It seems Joerg and itojun misunderstood that the reason is because
OpenBSD is using BSD auth. The correct reason is because OpenBSD
abandoned the traditional feature that users can change their
login-user from their login-shell, though.

Of course, su(1) is still setuid root even on OpenBSD.
--
soda
Jun-ichiro itojun Hagino
2003-09-14 02:19:58 UTC
Permalink
Post by Noriyuki Soda
Post by Roland Dowdeswell
Also, programs like login(1) or su(1) are not good examples because
they must be setuid root anyway to change the uid upon successful
authentication.
Well, login(1) isn't setuid root on OpenBSD.
It seems Joerg and itojun misunderstood that the reason is because
OpenBSD is using BSD auth. The correct reason is because OpenBSD
abandoned the traditional feature that users can change their
login-user from their login-shell, though.
have you ever used recent OpenBSD? login(1) in OpenBSD will exec su(1)
if username is passed, and effectively preserves "login foo" behavior.
if you have commnted without checking the fact, i suggest you to do
fact-checking before you post next time.

itojun


openbsd usr.bin/login/login.c
----------------------------
revision 1.49
date: 2002/10/16 01:08:56; author: millert; state: Exp; lines: +61 -39
Remove the setuid bit from /usr/bin/login. If login is run by a user
with a non-zero euid, it will now exec "su -L -l". The only things
that need to do this are shells with a "login" builtin and the emulation
that su(1) now does is good enough for this purpose.
Noriyuki Soda
2003-09-16 02:34:30 UTC
Permalink
Post by Jun-ichiro itojun Hagino
On Sun, 14 Sep 2003 11:19:58 +0900 (JST),
have you ever used recent OpenBSD?
No. I just looked at their makefile slightly.
That's the reason why I thought they abandoned the feature.
Post by Jun-ichiro itojun Hagino
login(1) in OpenBSD will exec su(1)
if username is passed, and effectively preserves "login foo" behavior.
if you have commnted without checking the fact, i suggest you to do
fact-checking before you post next time.
Thank you for the clarify.

But that doesn't affect my point.
Let me say my point again:

The reason why login(1) on OpenBSD isn't setuid root
isn't because OpenBSD is using BSD auth.

As you pointed out, the reason is because it internally calls
su(1) to switch the user id. And of course, the same thing can be with
PAM, too. Thus, the conclusion is same:

Refering /usr/bin/login as an example of the benefit of
BSD auth is just wrong.

If this still doesn't convince you, please re-read what you wrote
again.
Post by Jun-ichiro itojun Hagino
programs that needs authentication just need to be setgid "auth" (to
access authentication programs under /usr/libexec/auth).
And look at the mode of /usr/bin/login on OpenBSD, it isn't setgid "auth".
--
soda
Jeremy C. Reed
2003-09-14 02:22:20 UTC
Permalink
Post by Jun-ichiro itojun Hagino
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/at
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atq
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atrm
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/batch
-r-sr-xr-x 1 root wheel 24048 Sep 6 21:30 /usr/bin/crontab
These are easy fixes (and not related to any authentication as far as I
know).

Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)

Jeremy C. Reed
http://bsd.reedmedia.net/
Steven M. Bellovin
2003-09-14 02:28:19 UTC
Permalink
Post by Jeremy C. Reed
Post by Jun-ichiro itojun Hagino
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/at
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atq
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atrm
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/batch
-r-sr-xr-x 1 root wheel 24048 Sep 6 21:30 /usr/bin/crontab
These are easy fixes (and not related to any authentication as far as I
know).
Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)
That's a distinction without a difference, since a subverted crontab
could rewrite root's file, which would be executed as root by crond.


--Steve Bellovin, http://www.research.att.com/~smb
Jeremy C. Reed
2003-09-14 02:45:27 UTC
Permalink
Post by Steven M. Bellovin
Post by Jeremy C. Reed
Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)
That's a distinction without a difference, since a subverted crontab
could rewrite root's file, which would be executed as root by crond.
Can crontab be made smarter to only edit root's crontab if the user is
root and root's cron tab (or any other crontab of a uid 0) could be forced
to be saved outside of the standard tab directory.

And the cron daemon could check to never use a cron tab for a user which
has a uid of 0 from within the tabs directory and also will use the root's
tab which is a different location?



Jeremy C. Reed
http://www.reedmedia.net/
Andrew Brown
2003-09-14 04:34:36 UTC
Permalink
Post by Steven M. Bellovin
Post by Jeremy C. Reed
Post by Jun-ichiro itojun Hagino
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/at
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atq
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/atrm
-r-sr-xr-x 4 root wheel 23284 Sep 6 21:30 /usr/bin/batch
-r-sr-xr-x 1 root wheel 24048 Sep 6 21:30 /usr/bin/crontab
These are easy fixes (and not related to any authentication as far as I
know).
Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)
That's a distinction without a difference, since a subverted crontab
could rewrite root's file, which would be executed as root by crond.
well...since he said "making the cron tabs directory writable by that
group"...

what about this (silly fake output that describes what i thinking):

% ls -la /var/cron/tabs
total 4
drwx-wx--- 2 root crontabs 512 Aug 12 23:42 .
drwxr-xr-x 3 root wheel 512 May 11 17:14 ..
-rw------- 1 andrew crontabs 357 Mar 19 08:32 andrew
-rw------- 1 root crontabs 934 Aug 12 23:42 root
% ls -l /usr/bin/crontab
-r-xr-sr-x 1 root crontabs 24592 Aug 11 12:43 /usr/bin/crontab*

so that users can only use crontab to put a crontab in place, cron
runs as root so that cron itself can get stuff from there (and so that
it can setuid), and if it finds a file, it ensures that the crontab
named "george" is owned by "george" (and root's is root, etc).

heck, you could even put a socket in there called "-cron" (since
usernames can't start with a - anyway) that, when connected to, would
cause cron to rescan the crontabs directory. the crontab binary
would, of course, merely cd to that directory and then toss the
crontabs group privs.

just making stuff up late at night here...
--
|-----< "CODE WARRIOR" >-----|
***@daemon.org * "ah! i see you have the internet
***@graffiti.com (Andrew Brown) that goes *ping*!"
***@squooshy.com * "information is power -- share the wealth."
Ted Unangst
2003-09-14 23:42:01 UTC
Permalink
Post by Steven M. Bellovin
Post by Jeremy C. Reed
Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)
That's a distinction without a difference, since a subverted crontab
could rewrite root's file, which would be executed as root by crond.
how does a subverted setgid crontab write to
-rw------- 1 root crontab 918 Aug 18 2002 root
?
--
we used to hate people
now we just make fun of them
it's more effective that way
Todd C. Miller
2003-09-15 19:09:39 UTC
Permalink
Post by Jeremy C. Reed
These are easy fixes (and not related to any authentication as far as I
know).
Has there been any discussion on getting rid of setuid root and just using
setgid of cron-specific group? (And making the cron tabs directory
writable by that group.)
FYI, the latest ISC cron code supports running setgid instead of setuid.
You probably need to ask Vixie for a current shar file since the ISC
web site doesn't have anything later than cron_4.0_b1.shar. FWIW,
I've fed all the changes I've made to cron in OpenBSD back to Paul,
though what's in his tree doesn't contain the at/atrun stuff yet.

- todd
Charles Blundell
2003-09-13 21:28:28 UTC
Permalink
Post by Greg A. Woods
No, that's not really true. PAM and BSD Auth are authentication
frameworks. I'm talking only about a "shim" API that hides the
particular flavour of framework from applications.
Perhaps you could give function prototypes for this api?
Post by Greg A. Woods
I think you're not looking at how authentication fits into the system
and how authentication is used in production environments properly. All
the tools in pkgsrc already work perfectly fine with the existing getpw*
support in the native OS.
Two things: kerberos, s/key.
Greg A. Woods
2003-09-13 22:32:33 UTC
Permalink
[ On Saturday, September 13, 2003 at 22:28:28 (+0100), Charles Blundell wrote: ]
Subject: Re: BSD auth for NetBSD
Post by Greg A. Woods
No, that's not really true. PAM and BSD Auth are authentication
frameworks. I'm talking only about a "shim" API that hides the
particular flavour of framework from applications.
Perhaps you could give function prototypes for this api?
I'm working on it! :-) Note the person who first proposed it may
already have firmer ideas than mine....

(and prototypes alone do not an API make :-)

In any case it might look one heck of a lot like the one used by
applications for BSD Auth though -- with a couple of caveats needed to
bend to PAM's assumptions. I.e. while one might have a lot more
difficulty using a separate authenticator process as a proxy to PAM, the
adaption of the BSD Auth application API to alternately call PAM should
be relatively simple (at least given how I've seen both used in OpenBSD
and FreeBSD respectively).

It may be equally possible to wrap the BSD Auth API with functions that
look exactly like the PAM application API and similarly insert a
compile-time or run-time switch to call either out the back-end of this
shim.

It may even be possible to offer both APIs as shims to each other and
with a run-time and compile-time configurable switch in the middle so
that the appropriate back end can be chosen at will.

However from what I've seen of the two APIs to date I find the BSD Auth
application API to be by far the cleaner and more flexible of the two
(with the tiny caveat that BSD Auth's API currently doesn't require the
authentication session to be kept open for the life of the authenticated
session and though I'm not sure PAM really does require it be kept open
for the basic auth methods like unix passwords that is the way it has
been implemented in FreeBSD's login(1)).

Ideally I'd also like to come up with an even more simplified common
"wrapper" API for the common cases where one just wants all the normal
unixy things to happen, such as in login, ftpd, rcmd, or any other place
where a session is started and authenticated once for its lifetime with
a simple password (one-time, challenge, or normal secret) that the
library will obtain directly from the user via a specified R/W file
descriptor.
Post by Greg A. Woods
I think you're not looking at how authentication fits into the system
and how authentication is used in production environments properly. All
the tools in pkgsrc already work perfectly fine with the existing getpw*
support in the native OS.
Two things: kerberos, s/key.
Adding either PAM or BSD Auth doesn't really make supporting either of
these in third party code all that much easier. Third party developers
still pretty much have to be prepared to use native OS support for these
two mechanisms regardless of whether they also support some more generic
framework such as PAM and/or BSD Auth.

We have both kerberos and s/key natively supported in the base OS and I
was under the impression that all add-on packages in pkgsrc which needed
to be aware of at least Kerberos already had the necessary hooks to make
them aware of the native Kerberos libraries and utilities.

I'm a little less sure about how well existing packages work with
NetBSD's s/key support. I haven't tried s/key with Cyrus SASL lately,
for example, though I was hoping to get a chance to do exactly that very
soon. It should already work if I understand the "--enable-otp"
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-14 00:15:55 UTC
Permalink
On 1063492353 seconds since the Beginning of the UNIX epoch
Post by Greg A. Woods
Post by Charles Blundell
Two things: kerberos, s/key.
Adding either PAM or BSD Auth doesn't really make supporting either of
these in third party code all that much easier. Third party developers
still pretty much have to be prepared to use native OS support for these
two mechanisms regardless of whether they also support some more generic
framework such as PAM and/or BSD Auth.
What?? This is incorrect. If you actually use PAM (and probably
BSD Auth), you will note that the modules (or programs) will properly
allow users to log in and obtain tickets. You may be thinking
about making kerberized network connections, but that's not what
PAM or BSD Auth are trying to do anyway.
Post by Greg A. Woods
We have both kerberos and s/key natively supported in the base OS and I
was under the impression that all add-on packages in pkgsrc which needed
to be aware of at least Kerberos already had the necessary hooks to make
them aware of the native Kerberos libraries and utilities.
Not for accepting passwords in cases such as xlock, xscreensaver,
gdm, kdm, etc.
Post by Greg A. Woods
I'm a little less sure about how well existing packages work with
NetBSD's s/key support. I haven't tried s/key with Cyrus SASL lately,
for example, though I was hoping to get a chance to do exactly that very
soon. It should already work if I understand the "--enable-otp"
SASL is a different beast.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Greg A. Woods
2003-09-14 17:46:15 UTC
Permalink
[ On Saturday, September 13, 2003 at 20:15:55 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
Post by Greg A. Woods
Post by Charles Blundell
Two things: kerberos, s/key.
Adding either PAM or BSD Auth doesn't really make supporting either of
these in third party code all that much easier. Third party developers
still pretty much have to be prepared to use native OS support for these
two mechanisms regardless of whether they also support some more generic
framework such as PAM and/or BSD Auth.
What?? This is incorrect.
If you had actually read any of the code for any major third-party
applications (e.g. those found in pkgsrc) you would have seen that I am
in fact 100% correct. You should go back and read that code before you
make further blatant mistakes like that.
If you actually use PAM (and probably
BSD Auth)
Fortunately portable third party applications _cannot_ assume that PAM
is available (just as they cannot assume BSD Auth is available). (And
yes, this is a very good thing since there's no POSIX API for making
authentication requests and checks.)
Not for accepting passwords in cases such as xlock, xscreensaver,
gdm, kdm, etc.
In fact if you look at those programs you'll find they many of them do
have direct support for each of crypt(), krb_verify_user(),
pam_authenticate(), auth_call(), etc. (see xdm/greeter/verify.c, for
example, which supports everything but S/Key directly it seems).

Even CVS (for its stupid pserver protocol), includes such direct support
of at least Kerberos, as well as of course crypt().

Like I say above: read some more code!

Even a grep for the obvious function names in the obvious places would
have verified what I said initially to have been correct.
SASL is a different beast.
SASL as a protocol serves the same needs in a different environment.

However saslauthd does all of what I say above and will continue to do
so even if NetBSD joins either OpenBSD or FreeBSD in the "auth API wars".
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-14 18:43:18 UTC
Permalink
On 1063561575 seconds since the Beginning of the UNIX epoch
Post by Greg A. Woods
In fact if you look at those programs you'll find they many of them do
have direct support for each of crypt(), krb_verify_user(),
pam_authenticate(), auth_call(), etc. (see xdm/greeter/verify.c, for
example, which supports everything but S/Key directly it seems).
Even CVS (for its stupid pserver protocol), includes such direct support
of at least Kerberos, as well as of course crypt().
Like I say above: read some more code!
Even a grep for the obvious function names in the obvious places would
have verified what I said initially to have been correct.
The rather obvious fact that my Kerberos 5 password did not actually
let me log in via xdm(1) was the first clue that it didn't have
support. I tend to trust that a little more than reading the code.
A grep for the obvious function names in the obvious places was
the naive approach that I first took when trying to get xdm to DTRT
w.r.t. krb5 last year.

Luckily, though, you'll actually find if you examine the code that
it was written against an old beta version of MIT krb5 and does
not actually build let alone work with anything recent. So the
grep method or even a simple examination of the source without a
reasonable knowledge of the Kerberos 5 APIs is useless.

Perhaps the problem is that all the other projects get their Kerberos
5 support in xdm by using either PAM or BSD Auth and so there is
little impetus for the XFree86 developers to add direct support
for Kerberos 5.

All of the Kerberos 5 bits in the xdm in our source tree are in
support of kerberised X connections and defining the right bits to
get it to build will turn on all manner of broken code in the rest
of the tree (same old API issue.)

If you want it to work, please check out the patches that I made for
it:

http://www.imrryr.org/~elric/hacks/krb5/xdm-src.tar.gz

xlockmore has a similar story, works with MIT but not Heimdal.

Looking at the CVS code [again in the NetBSD source tree]:

$ find . -name \*.c | xargs grep krb5
./src/server.c:# include <krb5.h>
./src/server.c: krb5_context kc;
./src/server.c: krb5_principal p;
./src/server.c: krb5_init_context (&kc);
./src/server.c: || krb5_parse_name (kc, ((gss_buffer_t) &desc)->value, &p) != 0
./src/server.c: || krb5_aname_to_localname (kc, p, sizeof buf, buf) != 0
./src/server.c: || krb5_kuserok (kc, p, buf) != TRUE)
./src/server.c: krb5_free_principal (kc, p);
./src/server.c: krb5_free_context (kc);

Well, it has krb5 functions in it---so it must support Kerberos 5
passwords, right? Well, actually those functions are specifically
in support of gserver and deal with kerberised connections not accepting
Kerberos 5 passwords.

If you look at src/server.c line 5518, you'll find check_password()
which from my initial examination supports only CVS specific
passwords (via check_repository_password()) and standard UNIX
passwords (starting on line 5543.)
Post by Greg A. Woods
In fact if you look at those programs you'll find they many of them do
have direct support for each of crypt(), krb_verify_user(),
pam_authenticate(), auth_call(), etc. (see xdm/greeter/verify.c, for
example, which supports everything but S/Key directly it seems).
The xdm/greeter/verify.c in our source tree does not support Kerberos 5,
only Kerberos 4. So that leaves it supporting only half of the auth
methods that login(1) supports.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Greg A. Woods
2003-09-14 22:31:45 UTC
Permalink
[ On Sunday, September 14, 2003 at 14:43:18 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
The rather obvious fact that my Kerberos 5 password did not actually
let me log in via xdm(1) was the first clue that it didn't have
support. I tend to trust that a little more than reading the code.
Well, reading the right code might reveal to you that you've made a very
naive coice of trusting whomever built your binaries.

The point is that native support for kerberos (and s/key) will continue
to be found in major applications regardless of what NetBSD does, just
as it _is_ there today despite your attempt to claim otherwise.

Furthermore many people will suggest that the problem with kerberos
support on NetBSD is with the kerberos APIs offered by NetBSD, not the
choice of APIs made by the applications, and they may not be far from
the truth.
Luckily, though, you'll actually find if you examine the code that
it was written against an old beta version of MIT krb5 and does
not actually build let alone work with anything recent.
So? Are you not capable of fixing it? All the pointers and hooks are
there and it's just a matter of updating the code to meet the API
offered by the in-tree implementation. As you've hopefully already seen
there is a canonical example of how it should work in usr.bin/login.
Perhaps the problem is that all the other projects get their Kerberos
5 support in xdm by using either PAM or BSD Auth and so there is
little impetus for the XFree86 developers to add direct support
for Kerberos 5.
Perhaps, but why are you looking for blame instead of just fixing the
code? If someone offered good clean patches that produced working
functionality on at least one platform such as NetBSD then I'm sure
they'd stand a decent chance of being accepted and included in the base
Xfree86 release.

I don't use kerberos (currently) and so I have no impetus to work on
such patches, but presumably you do.
All of the Kerberos 5 bits in the xdm in our source tree are in
support of kerberised X connections
Sure, OK, whatever. The fact remain s that there's some native support
for keberos in the greeter too and if someone were to update it to
support ther krb5 APIs offered natively by NetBSD then it would be there
for everyone.
and defining the right bits to
get it to build will turn on all manner of broken code in the rest
of the tree (same old API issue.)
Again, why are you looking for blame instead of just fixing the code?
The xdm/greeter/verify.c in our source tree does not support Kerberos 5,
only Kerberos 4. So that leaves it supporting only half of the auth
methods that login(1) supports.
Well, fix it then! You said xdm didn't have "kerberos" support. I
showed that it does. You say well, it's not "Kerberos 5". I say you're
whining about nothing. Xdm can, and should, be fixed to have native
krb5 support regardless of what NetBSD does in the "auth wars". Free
code doesn't grow on trees though and so if you're a krb5 user capable
of fixing xdm then you should get right to it!
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-15 02:24:49 UTC
Permalink
On 1063578705 seconds since the Beginning of the UNIX epoch
Post by Greg A. Woods
Well, reading the right code might reveal to you that you've made a very
naive coice of trusting whomever built your binaries.
The point is that native support for kerberos (and s/key) will continue
to be found in major applications regardless of what NetBSD does, just
as it _is_ there today despite your attempt to claim otherwise.
None of the programs that you pointed to actually contain working
Kerberos 5 password validation code. And some of them didn't even
contain Kerberos 4 password validation code.

I've actually read the code and tried to get it to work, and didn't
just do what you apparently did which was:

$ cd /usr/xsrc/xfree86/xc/programs/xdm
$ find . -name \*.c | xargs grep krb5 && echo "xdm supports krb5"
Post by Greg A. Woods
So? Are you not capable of fixing it? All the pointers and hooks are
there and it's just a matter of updating the code to meet the API
offered by the in-tree implementation. As you've hopefully already seen
there is a canonical example of how it should work in usr.bin/login.
Yes, and I did. I put a pointer to my work in the e-mail to which
you replied. By the time that I was done, I had pretty much thrown
away the code that they provided because it was too old and tangled
in with other functionality which hasn't worked in a decade to fix.

I didn't check it in because fixing it that way is suboptimal.
The right way to fix it is to provide a PAM client side API as part
of the base OS.
Post by Greg A. Woods
Post by Roland Dowdeswell
The xdm/greeter/verify.c in our source tree does not support Kerberos 5,
only Kerberos 4. So that leaves it supporting only half of the auth
methods that login(1) supports.
Well, fix it then! You said xdm didn't have "kerberos" support. I
showed that it does. You say well, it's not "Kerberos 5". I say you're
whining about nothing. Xdm can, and should, be fixed to have native
krb5 support regardless of what NetBSD does in the "auth wars". Free
code doesn't grow on trees though and so if you're a krb5 user capable
of fixing xdm then you should get right to it!
I'll thank you to not volunteer my time for pointless tasks whose
sole purpose is to satisfy Greg Woods' anti-PAM jihad. If there
was actually any level of need for xdm having native krb5 support
then I'd imagine that some time in the last decade it would have
grown it. There is no need because xdm supports PAM and BSD Auth.

I'm sorry, I don't think that I can continue this conversation
without it becoming a flame war so I'm bowing out.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Greg A. Woods
2003-09-15 16:07:55 UTC
Permalink
[ On Sunday, September 14, 2003 at 22:24:49 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
None of the programs that you pointed to actually contain working
Kerberos 5 password validation code.
I didn't say they did -- I said they supported "kerberos".

You're the one who failed to include a version specifier in the first
place, and I'm not going to allow you to get away with picking stupid
nits like as a result even if it means I have to do the same in return.
And some of them didn't even
contain Kerberos 4 password validation code.
The current copy of xdm (xsrc/xfree/xc/programs/xdm) and the current
version of xlockmore in pkgsrc both support kerberos.
I've actually read the code and tried to get it to work,
So, "tried"? You gave up? It appears not. If you succeeded then the
fact you're effectively witholding your changes is making your whole
argument look rather hypocritical.
Yes, and I did. I put a pointer to my work in the e-mail to which
you replied. By the time that I was done, I had pretty much thrown
away the code that they provided because it was too old and tangled
in with other functionality which hasn't worked in a decade to fix.
Ah, well, there you go. Did you see this old message before you
started? Perhaps not given that you re-did some of the same work over a
year later.

http://mail-index.netbsd.org/current-users/2001/01/19/0013.html

Will probably should have used send-pr, and maybe eventually did (as I
didn't check).....
I didn't check it in because fixing it that way is suboptimal.
The right way to fix it is to provide a PAM client side API as part
of the base OS.
Nope, Bzzzt. WRONG.

There is _still_ no PAM client API in the base OS. The only right fix,
right now, is to use the existing APIs in the existing applications.


Anyway, you started this by complaining about what you thought was a
lack of support for native authentication APIs (i.e. not frameworks) in
third party applications in pkgrsrc. I then showed you that all the
major ones already had support for all the native auth APIs you
mentioned. You then complained that some of it didn't work for you and
now you say you've fixed some of it to work but you've effectively, or
at least apparently, withheld your fixes from both the NetBSD community
_and_ from the third party developers who would almost certainly have
accepted your changes.

So your whine about third party apps has minor merit, though you are
very confused about what third party developers will continue to do.

Your whine about in-tree applications such as xdm, which you've already
fixed for yourself (but only yourself) has no merit whatsoever.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-14 02:08:02 UTC
Permalink
Post by Greg A. Woods
No, that's not really true. PAM and BSD Auth are authentication
frameworks. I'm talking only about a "shim" API that hides the
particular flavour of framework from applications.
...and that defeats the whole purpose of using either.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-14 17:14:31 UTC
Permalink
[ On Saturday, September 13, 2003 at 19:08:02 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
Post by Greg A. Woods
No, that's not really true. PAM and BSD Auth are authentication
frameworks. I'm talking only about a "shim" API that hides the
particular flavour of framework from applications.
...and that defeats the whole purpose of using either.
I don't thinks so! Why do you think so? Are you really sure you
understand what I'm trying to describe?
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-14 17:52:25 UTC
Permalink
[...and that defeats the whole purpose of using either.
I don't thinks so! Why do you think so? Are you really sure you
understand what I'm trying to describe?
One of the major features of using PAM is API compatibility with
PAM-using applications (of which there are many, especially compared to
BSD Auth).

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-14 22:10:34 UTC
Permalink
[ On Sunday, September 14, 2003 at 10:52:25 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
[...and that defeats the whole purpose of using either.
I don't think so! Why do you think so? Are you really sure you
understand what I'm trying to describe?
One of the major features of using PAM is API compatibility with
PAM-using applications (of which there are many, especially compared to
BSD Auth).
That answer simply does not have anything whatsoever to do with my
original statement.

In fact on the contrary you are now simply confirming the reason for
using a shim or wrapper API, especially a two-way one as I suggested, in
the first place -- i.e. an API which includes both BSD Auth client
functions and PAM client functions and which can be configured (at
runtime or at compile time) to call either framework out the back end.
Such a shim or wrapper API actually makes it better for everyone since
with any application would use either framework without (as much)
porting effort regardless of which client API it might support best
natively.

I.e. such a shim API does exactly the opposite of defeating "the whole
purpose" of using either authentication framework -- rather it makes it
possible for any application to use either framework transparently thus
allowing the purpose of either framework to be fulfilled regardless of
the application author's initial choice of API!

To me the "whole purpose" of using BSD Auth is to move the authenticator
code out into a sub-process. The way this is done behind the scenes has
nothing whatsoever to do with the client API since in the end the BSD
Auth and PAM client APIs are both almost identical at a functional
level. I.e. except for the changes necessar to the layout of the data
structures and parameters you could almost use 'sed' to map one's
functions to another. For example Using a BSD Auth authenticator that
knows how to set an AFS PAG for its parent process will still work even
if the caller is actually using the PAM client API. The caller doesn't
really even know that the PAG has been created, let alone how.

I believe this can be done without too much hassle or effort, assuming
we're willing to force one tiny but significant change on the BSD Auth
API, which I've already discussed (and which would also be necessary
even if the choice were simply to implement only the BSD Auth client API
and then allow it behind the scenes to call upon PAM).
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-15 01:07:38 UTC
Permalink
Post by Greg A. Woods
In fact on the contrary you are now simply confirming the reason for
using a shim or wrapper API, especially a two-way one as I suggested, in
the first place -- i.e. an API which includes both BSD Auth client
functions and PAM client functions and which can be configured (at
runtime or at compile time) to call either framework out the back end.
Such a shim or wrapper API actually makes it better for everyone since
with any application would use either framework without (as much)
porting effort regardless of which client API it might support best
natively.
It doesn't make it better for ANYONE, since there are no applications
which use your hypothetical "shim" API.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-15 14:44:56 UTC
Permalink
[ On Sunday, September 14, 2003 at 18:07:38 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
It doesn't make it better for ANYONE, since there are no applications
which use your hypothetical "shim" API.
Excuse me? Did you forget to _think_ today? _ALL_ applications which
use either BSD Auth _or_ PAM already use that proposed API. ALL OF THEM.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-15 15:09:56 UTC
Permalink
Post by Greg A. Woods
Post by Jason Thorpe
It doesn't make it better for ANYONE, since there are no applications
which use your hypothetical "shim" API.
Excuse me? Did you forget to _think_ today? _ALL_ applications which
use either BSD Auth _or_ PAM already use that proposed API. ALL OF THEM.
Then you must be saying that your "shim" API is actually the PAM API or
the BSD Auth API. Sorry, that simply wasn't clear (to me, at least) in
any of your previous messages on the subject.

If that is the case, then the obvious choice is the PAM API, since it
is supported by more applications (last time I checked, anyway).

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-15 20:04:23 UTC
Permalink
[ On Monday, September 15, 2003 at 08:09:56 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
Then you must be saying that your "shim" API is actually the PAM API or
the BSD Auth API. Sorry, that simply wasn't clear (to me, at least) in
any of your previous messages on the subject.
Not "or" -- "and". Sorry I wasn't more clear about this -- I've been
trying very hard to be very explicit about exactly what I mean in order
to try to avoid this very type of misunderstanding. Yes it means you
have to read more words but every time I write fewer words people fill
in on their own and more often than not put the wrong words in my mouth.
If that is the case, then the obvious choice is the PAM API, since it
is supported by more applications (last time I checked, anyway).
No, that's not the "obvious choice" -- you seem to have ignored all the
reasons I and others have given for wanting not just the BSD Auth
framework but also the client API it provides.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
David Maxwell
2003-09-15 19:41:15 UTC
Permalink
Post by Greg A. Woods
[ On Sunday, September 14, 2003 at 18:07:38 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
It doesn't make it better for ANYONE, since there are no applications
which use your hypothetical "shim" API.
Excuse me? Did you forget to _think_ today? _ALL_ applications which
use either BSD Auth _or_ PAM already use that proposed API. ALL OF THEM.
I thought this discussion was going rather well, until this comment. I'd
consider that remark pretty inflamatory and unproductive.

Play nice, please...
--
David Maxwell, ***@vex.net|***@maxwell.net -->
Net Musing #5: Redundancy in a network doesn't mean two of everything and
half the staff to run it.
- Tomas T. Peiser, CET
Greywolf
2003-09-15 19:47:28 UTC
Permalink
May I please point out with regard to the dynamic-vs-static-linking stuff
that it should not be mandated in order to run cool-and-nifty stuff
like authentication mechanisms?

You will find that the anti-PAM and anti-dynamic-linking wars actually
do feed themselves quite well, as it's a circular argument. If something
can be done by which statically linked binaries can do a modicum of dynamic
loading, I, for one, would be both very appreciative and quite impressed.

I doubt, too, sincerely, that I am speaking just for myself when I
state that I don't think anything should be forced down anyone's throat
(on the side of the end user), and that's putting it as neutrally as I
possibly can; any implications from that statement will be injected by
the reader. Take it as you will.

--*greywolf;
--
NetBSD: Power Your Net.
Greg A. Woods
2003-09-15 21:24:58 UTC
Permalink
[ On Monday, September 15, 2003 at 12:47:28 (-0700), Greywolf wrote: ]
Subject: Re: BSD auth for NetBSD
If something
can be done by which statically linked binaries can do a modicum of dynamic
loading, I, for one, would be both very appreciative and quite impressed.
I'd be very un-impressed with such a mechanism.

One of the major security-related features of static-linked programs is
that the processes they run as _cannot_ dynamically load new code.

Now if there were a more flexible "fake" libdl that could stub out all
the loading functions and just flip some pointers in a jump table to
select the entry-points for an already loaded and linked module, then we
could gain the benefit of static linking without having to change code....

That said though it must also be said that the vast majority of "plugin"
code that has to run in the same context and address space as the caller
is just an example of bad design. Use of multiple processes with a
fast, clean, local IPC mechanism beats the hell out of plugin code on
many fronts, losing only on raw simplicity and absolute maximum possible
performance.

Note that often in general purpose unix environments the cost of static
linking is easily offset by the savings gained from not having to run
ld.so on every invocation, and that goes double for anything which calls
the real dlopen() too. Jason's insult about static linking looks rather
hypocritical in face of all the work he did on a "real" vfork()
implementation, especially when you consider that the result is often
less than can be achieved simply by static-linking the programs which
get invoked many times during a larger job.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Todd Vierling
2003-09-15 21:35:51 UTC
Permalink
On Mon, 15 Sep 2003, Greg A. Woods wrote:

: One of the major security-related features of static-linked programs is
: that the processes they run as _cannot_ dynamically load new code.

I really need to get the number of your dealer. He sells the Good Stuff.

It has been demonstrated many times that proliferation of static binaries is
*detrimental* to security maintenance, because they require recompilation to
gain fixes to libc (and other dependent libraries). Sun has talked at
length about this issue, as has TNF and countless others.

The only security problem with dynamic linking has been with programmer
error -- relating to things such as setuid binaries, which are specifically
forbidden from running arbitrary code via LD_PRELOAD/LD_LIBRARY_PATH and the
like. These were bugs in the dynamic linker which needed to be fixed; these
were *not* evidence that dynamic linking was somehow bad for security.

Demonstrated fallacy. Next argument?

: That said though it must also be said that the vast majority of "plugin"
: code that has to run in the same context and address space as the caller
: is just an example of bad design.

A matter of perspective and experience; much research has also focused on
how modular code is actually *better* design. So, this is a red herring.
Next argument?

: Note that often in general purpose unix environments the cost of static
: linking is easily offset by the savings gained from not having to run
: ld.so on every invocation, and that goes double for anything which calls
: the real dlopen() too.

This is a cost that has been accepted by OS developers for some time,
insofar that it has many benefits (not just size of binaries) -- see my
comment about security, above.

Thus, this is irrelevant, as Unix systems are not going back the other way
to statically linking huge parts of the system just for a minor performance
boost. Next argument?
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Greg A. Woods
2003-09-15 23:38:27 UTC
Permalink
[ On Monday, September 15, 2003 at 17:35:51 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
It has been demonstrated many times that proliferation of static binaries is
*detrimental* to security maintenance, because they require recompilation to
gain fixes to libc (and other dependent libraries). Sun has talked at
length about this issue, as has TNF and countless others.
You really didn't pay attention to what I said.

The _benefit_ of static binaries is that the processes run from them
_cannot_ dynamically load new code.

The maintenance issues you speak of is completely separate and must be
balanced _against_ the benefit I speak of.

Sun is not an Open Source vendor, nor is M$ for that matter. They have
_very_ different concerns for their operating systems than any open
source system has.

While _you_, or Sun, or even Wasabi Systems (and thus perhaps TNF as
well), may have to think about weighing the cost of relinking against
libc vs. the cost of allowing sensitive processes to load new and
potentially foreign code; _I_ do not have to worry about this issue.
For me the added cost of upgrading static linked systems is very
literally not measurably significant. I already build static linked
systems and I can deploy a fix to libc to my customers with just as much
ease and speed as I could deploy one by way of an updated to a shared
library. That is true even if I always assume that the affected object
code is used by _every_ system binary (which in practice is rarely true).

I have indeed seen all the hand-waving about how much easier it is to
install a single file or two vs. a whole set of files. I know perhaps
better than anyone the issues related with identifying exactly those
binaries which contain object code derived from source containing a
known bug, especially in a unix development environment. However it is
_because_ I understand all these issues in depth that I've chosen to
build static-linked systems, not in spite of them.

Meanwhile shared libraries have demonstrably created enormous
maintenance headaches for almost every non-security related issue
(witness the inability of NetBSD to bump the major number on libc and
the ongoing and ever increasing complication this causes for the
ever-changing API it tries to implement -- and that's just the tip of
the iceberg of problems for NetBSD, never mind the industry as a whole).
I don't know a single software engineer with any significant experience
who can even begin to say with a straight face that shared libraries
have made their jobs easier. In fact several the software engineers I
know personally who have the most, and the most recognized and
respected, experience are highly critical of the kind of shared library
mechanisms employed by NetBSD. Indeed these problems are not directly a
fault of dynamic linking alone, but they are tied to the way NetBSD
implements dynamic linking (and they are partly tied to the
implementation language too). The fact is though that's all we've got
for now and so we either endure the problems, or stick our heads in the
sand, or where possible simply avoid using such flawed features.
The only security problem with dynamic linking has been with programmer
error
(Well, no, not exactly, but....)

As are many software security problems. Your point is meaningless in
this context. Finger pointing or saying that bugs must be fixed
regardless doesn't change the fact that bugs occur and the ability to
load new code remains a significant vulnerability.

The fact that we've only seen active exploits for dynamic loading bugs
in operating system kernels only relates to the relative benefit to the
attacker of choosing the kernel as a primary target.
A matter of perspective and experience; much research has also focused on
how modular code is actually *better* design. So, this is a red herring.
Next argument?
"Modular code" != "plugin code" Please don't think you can pull such
obvious bait and switch attack and get away with it. You have no point.
_Your_ argument on this point is the one chock full of red herrings.
This is a cost that has been accepted by OS developers for some time,
insofar that it has many benefits (not just size of binaries) -- see my
comment about security, above.
Well, it's not a cost that at least some OS users have been truly
willing to endure. Even some NetBSD users (other than myself) have
learned that the performance benefits of static linking in cannot be
ignored. Even some NetBSD users (other than myself) have come to
understand the upgrade headaches caused by the kind of dynamic libraries
NetBSD uses.

Thanks a great many economic and societal factors we no longer have to
worry anywhere near as much about the size of static-linked binaries.
Even a complete alpha build of NetBSD with '-g -static' isn't very large
in modern terms (I know -- I'm running one right now).
Thus, this is irrelevant, as Unix systems are not going back the other way
to statically linking huge parts of the system just for a minor performance
boost. Next argument?
Well, since I do build static-linked systems, and since the resulting
performance boost is often enough just as significant as the one Jason
achieved by re-instating an infamous and very poorly designed hack into
the system, I think you're being very hypocritical. Do you really
expect anyone to fall for this? Do you really think all NetBSD users
are so naive that you can pull this wool over their eyes?
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greywolf
2003-09-16 00:10:04 UTC
Permalink
Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> Well, since I do build static-linked systems, and since the resulting
GAW> performance boost is often enough just as significant as the one Jason
GAW> achieved by re-instating an infamous and very poorly designed hack into
GAW> the system, I think you're being very hypocritical. Do you really
GAW> expect anyone to fall for this? Do you really think all NetBSD users
GAW> are so naive that you can pull this wool over their eyes?

...whoa, Whoa, WHOA!

CAN we please stop the insultfest? It's counterproductive to the original
ideals.

Is there ANY WAY we can look at this and say that both sides have merit?

I *still* think making everything dynamically loaded was non-optimal,
/rescue notwithstanding, but that's my opinion, and I've thus far been
given the option of not building my system that way. Thank you again
for making that possible.

I commented on the mixing of static and dynamic linking because it was
listed as a major hurdle for the PAM stuff. I didn't *care for* PAM
because it will ultimately be forcing a particular paradigm down my throat
-- I feel it throws down the gauntlet and states that if I wish to proceed
along the path, I must throw away everything to which I have become
accustomed, and I must accept PAM as my saviour, regardless of whether or
not I choose to use it. That said, please see the words "I feel". I
am aware that I may be quite misguided; if this is the case, then some
words of reassurance to the contrary of my misguided hunch will be
gratefully accepted.

Other than that I am trying to remain neutral and offer some contributions
for thought in order to get the mortar-set brains of the staunch of each
side to crack loose and at least look at the other side of the coin.
Both sides will benefit from that exercise.

As far as vfork() goes, if we're going to crack THAT old nut again,
while it might appear to be a "hack", it *does* buy significant
improvements on execution in "specific situations" (which happen to
occur rather frequently!). As well, even if it was a hack for certain
hardware, *to me*, that kind of innovation is the sort of thing which
_can_ lead to great things!

I liked the proposition of the rfork() call, by the way. We could take
that somewhere, I think.

For what it's worth, to sum up (my opinion):

- vfork was a *cool* hack.

- Performance-wise, I don't perceive a huge gain on dynamic linking vs.
static linking. I had a problem with there being a broader point of
failure in the dynamic libs and the linker. It still rubs me the wrong
way. But I have the option to rebuild The Old Way. Please don't lose
that. In fact, I had to help someone semi-recently with their system
during an upgrade because it wasn't very forgiving with the wrong
order/incompletion of the upgrade. They didn't have /rescue, and they
got the repeated dreaded "Bad exec format" message with all the new
binaries. A reboot caused a "panic: init died" because something went
wrong. Nothing totally tragic, mind you, but it was kind of annoying.

- I see pros and cons to BSD Auth and PAM; my issue with PAM is enforced
dynamic linking of everything to the point that I won't be able to
rebuild as I need to.

- Policy decisions sometimes need to be made, but it's really a lot nicer
not to have them forced upon one.

If all I've done with my comments is to incite flame after flame, then
my intentions have been misinterpreted. I'm no grand hacker, no prodigious
programmer, certainly not on the scale of many of you. But I'm always
learning, always hungry to see what I can glean from what's happening.

I'd hope that those of you who are so dead-set in your mindset haven't
decided that you know so much that you feel you cannot possibly learn
any more.

--*greywolf;
--
NetBSD: true inheritors of the UNIX(tm) legacy.
der Mouse
2003-09-16 01:35:32 UTC
Permalink
Post by Greg A. Woods
The _benefit_ of static binaries is that the processes run from them
_cannot_ dynamically load new code.
If you believe that you are deluding yourself. At most, they cannot
dynamically load new code using the OS's dynamic-linker facilities, and
I'm not entirely sure of even that.

There is a security benefit accruing to static linking related to
dynamic loading, but this isn't it. I've had a few stabs at stating
what it is, but haven't found any short way of putting it - anyone?

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Michael Richardson
2003-09-16 02:30:37 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Post by Greg A. Woods
The _benefit_ of static binaries is that the processes run from them
_cannot_ dynamically load new code.
der> If you believe that you are deluding yourself. At most, they cannot
der> dynamically load new code using the OS's dynamic-linker facilities,
der> and I'm not entirely sure of even that.

Of course, any program can open(2) a file, read it in, and perhaps even
cause it to execute. We could prevent that my making data segments
non-executable, but this would likely bite in many places.
Still, it would be a nice "capability" to have.

der> There is a security benefit accruing to static linking related to
der> dynamic loading, but this isn't it. I've had a few stabs at stating
der> what it is, but haven't found any short way of putting it - anyone?

I'll tell you why I don't like dynamic linking, particularly for critical
system components: file and system management.

Do you know how many times I've had to rescue RedHat systems when the
(DUE TO SECURITY VULNERABILITY!) to the shared libraries left the system
in a state where the PAM (YES!) was broken and nobody could login? Or worse,
you can even type "ln" because /lib/ld-linux.so.2 is incompatible with
/lib/glibc-X.Y.Z?
Linux is rapidly approaching Windows-Style DLL bit-rot.

I find it much easier to do:
% /sbin/md5sum /sbin/login

and compare that value to a known to be good (non-trojan'ed) /sbin/login,
knowing that since it doesn't load anything, it can't be trojan'ed by libc
or ld screwing. I just find static linked binaries easier to cope with,
easier to upgrade, and easier to verify.

The situation is 1000x worse if you consider things like GNOME and KDE.
Remember that according to the gospel of the friendly desktop, I'm supposed
to trust a lot of these programs running as root! (This is not a rant
against NetBSD, clearly we don't believe that. But those who know I've been
doing Linux work for the past two years, might wonder why all my critical
infrastructure is still running NetBSD)

Maybe, as some have said, this is my delusion - maybe Solaris 9 gets it
done so correctly that I'd just rave when I saw it - but RedHat sure doesn't.
Debian seems to do better - but only because they understand that making
be upgrade things to get security patches doesn't fly.

] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
Todd Vierling
2003-09-16 02:42:53 UTC
Permalink
On Mon, 15 Sep 2003, Michael Richardson wrote:

: I'll tell you why I don't like dynamic linking, particularly for critical
: system components: file and system management.
:
: Do you know how many times I've had to rescue RedHat systems when the
: (DUE TO SECURITY VULNERABILITY!) to the shared libraries left the system
: in a state where the PAM (YES!) was broken and nobody could login? Or worse,
: you can even type "ln" because /lib/ld-linux.so.2 is incompatible with
: /lib/glibc-X.Y.Z?

: Debian seems to do better - but only because they understand that making
: be upgrade things to get security patches doesn't fly.

Given the Debian GNU[tm]/NetBSD project attempt, it seems to me that a
sizable fraction of the smarter Linux minds use Debian. My current employer
uses Debian GNU[tm]/Linux heavily too, and after finally getting over my
last bits of learning curve between different distributions, I've come to
understand why.

The biggest problem afflicting most Linux distributions is that of too many
ladles in the soup. Things like glibc, login, su, etc. are released
separately on their own random release schedules. Though not a direct cause
of the compatibility-drift problem, this fosters an approach to development
that leaves backwards compatibility as a rarely executed afterthought.
Debian attempts to counter this mindset by testing for compatibility in a
more active manner at each critical package's release.

Traditional *BSDs have a leg up on a lot of these problems, in that the base
OS is monolithic by design. Even with the fledgling concept of NetBSD
system packages still hanging in limbo, the plan is not to split out all
manner of system code into separately tracked release schedules; the OS is
released as a whole. This helps encourage more extensive testing of fixes
to the infrastructure (libc, ld.so, etc.) against the OS as a whole, not
just against a static dejagnu testsuite.
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Greg A. Woods
2003-09-16 07:04:26 UTC
Permalink
[ On Monday, September 15, 2003 at 22:42:53 (-0400), Todd Vierling wrote: ]
Subject: Re: static linking for NetBSD
Traditional *BSDs have a leg up on a lot of these problems, in that the base
OS is monolithic by design. Even with the fledgling concept of NetBSD
system packages still hanging in limbo, the plan is not to split out all
manner of system code into separately tracked release schedules; the OS is
released as a whole. This helps encourage more extensive testing of fixes
to the infrastructure (libc, ld.so, etc.) against the OS as a whole, not
just against a static dejagnu testsuite.
It still doesn't solve any of the real underlying problems with
un-hygenic shared libraries -- it just papers over them with a hell of a
lot of unnecessary effort.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Brett Lymn
2003-09-16 02:59:52 UTC
Permalink
Post by Michael Richardson
Linux is rapidly approaching Windows-Style DLL bit-rot.
Errrr Linux is not a good thing to benchmark against - the horrors of
incompatiable versions of glibc is unspeakable. A shared libary that
is generated by people whose philosophy seems to be "update to the
latest coz we cannot be arsed with backwared compatiability" is no
argument that shared libraries are bad.
Post by Michael Richardson
% /sbin/md5sum /sbin/login
And you actually trust your md5sum is not trojaned? How interesting.
Post by Michael Richardson
and compare that value to a known to be good (non-trojan'ed) /sbin/login,
knowing that since it doesn't load anything, it can't be trojan'ed by libc
or ld screwing. I just find static linked binaries easier to cope with,
easier to upgrade, and easier to verify.
Feh - use verified exec then.
Post by Michael Richardson
Maybe, as some have said, this is my delusion - maybe Solaris 9 gets it
done so correctly that I'd just rave when I saw it - but RedHat sure doesn't.
Debian seems to do better - but only because they understand that making
be upgrade things to get security patches doesn't fly.
Having managed Sun systems for many years, yes, Sun do get it pretty
much right. I can apply patches for shared libraries to my system
without lossage occuring, my binaries that were compiled on a Solaris
2.5 machine still run fine on my Solaris 9 machine (modulo kernel
grovelling ones which may break). I have had troubles getting a RH8
binary running in RH9 due to, what seems to be, arbitrary interface
changes in glibc - trying to point at linux as an example of why
shared libraries is bad is dodgy, their philosophy is wrong which
flows down to their implementation which causes pain and lossage.
NetBSD, at least, works to avoid doing that.
--
Brett Lymn
Michael Richardson
2003-09-16 03:11:47 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Brett> Errrr Linux is not a good thing to benchmark against - the horrors

Yes, maybe a good point.
Post by Michael Richardson
% /sbin/md5sum /sbin/login
Brett> And you actually trust your md5sum is not trojaned? How
Brett> interesting.

I give this example metaphorically :-)

Brett> Having managed Sun systems for many years, yes, Sun do get it pretty
Brett> much right. I can apply patches for shared libraries to my system

Sounds great. I stopped using Sun's in day to day use sometime around
Solaris 2.3, when the Sparc port starting being useable :-)

Brett> grovelling ones which may break). I have had troubles getting a RH8
Brett> binary running in RH9 due to, what seems to be, arbitrary interface
Brett> changes in glibc - trying to point at linux as an example of why
Brett> shared libraries is bad is dodgy, their philosophy is wrong which
Brett> flows down to their implementation which causes pain and lossage.
Brett> NetBSD, at least, works to avoid doing that.

But, we still share code with them: X, KDE, GNOME. At least they were
optional. That's why I don't want PAM in my /bin/login. I don't want to
share that incompetence!

The fact that I don't need it for anything I do, while BSD auth provides
some things that I've found useful also sways me.

] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
Brett Lymn
2003-09-16 04:57:03 UTC
Permalink
Post by Michael Richardson
I give this example metaphorically :-)
:)
Post by Michael Richardson
But, we still share code with them: X, KDE, GNOME. At least they were
optional. That's why I don't want PAM in my /bin/login. I don't want to
share that incompetence!
Ah - now we get to implementation issues...I cannot recall if the
proposed PAM implementation was an import of other code or a NetBSD
specific implementation. Rejecting PAM out of hand because other
implementations suck (versus the API/specification) is not really
valid.
Post by Michael Richardson
The fact that I don't need it for anything I do, while BSD auth provides
some things that I've found useful also sways me.
Having no personal interest in any of the approaches it seems to me
that _if_ BSD auth can be layered over the top of PAM then we will
have a good thing. We cannot ignore the direction most other vendors
are going because we will just be left as a lone voice in the
wilderness... another reason not to use NetBSD, something we must
avoid.
--
Brett Lymn
Greg A. Woods
2003-09-16 07:11:07 UTC
Permalink
[ On Tuesday, September 16, 2003 at 12:29:52 (+0930), Brett Lymn wrote: ]
Subject: Re: static linking for NetBSD
Feh - use verified exec then.
I'd still like to see a proper mathematical proof of that concept which
includes coverage of the bootstrap issue.

There are just too many catch-22's in it for me to believe it does
anything more than obfuscate the real problems and just provide a false
sense of security.

The parmount rule of software security is still: K.I.S.S.

Checking what amounts to the same thing twice doesn't seem to add any
assurance to me, and instead it only seems to add unnecessary complexity.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greg A. Woods
2003-09-16 07:00:15 UTC
Permalink
[ On Monday, September 15, 2003 at 21:35:32 (-0400), der Mouse wrote: ]
Subject: Re: static linking for NetBSD
Post by Greg A. Woods
The _benefit_ of static binaries is that the processes run from them
_cannot_ dynamically load new code.
If you believe that you are deluding yourself. At most, they cannot
dynamically load new code using the OS's dynamic-linker facilities, and
I'm not entirely sure of even that.
Well it's a lot more complex than that to subvert static binaries, but
you're right there are a few minor tweaks necessary in the kernel to
really lock things down the way they should be locked down.
There is a security benefit accruing to static linking related to
dynamic loading, but this isn't it. I've had a few stabs at stating
what it is, but haven't found any short way of putting it - anyone?
Perhaps this is what you mean:

One of the bigger benefits I didn't point out, but which has been
pointed out several times previously by others, is that when you static
link program that doesn't call, for example system() or popen(), those
functions are simply not available at all in the text segment of the
running process, but on the other hand if you dynamically link the same
program with libc then those functions, along with all the rest of libc,
_is_ available immediately in the address space of the process. This
means keeping sensitive programs small, and static-linked, can
dramatically increases the effort necessary for any attacker to exploit
something like an integer overflow.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Todd Vierling
2003-09-16 01:38:26 UTC
Permalink
[I should kick myself for feeding the troll, but sometines it's worth
watching the troll squirm.]

On Mon, 15 Sep 2003, Greg A. Woods wrote:

: You really didn't pay attention to what I said.

"No, dear," I understood exactly what you said. To wit:

: The maintenance issues you speak of is completely separate and must be
: balanced _against_ the benefit I speak of.

This repeats one of my sentences, pretty much verbatim, so I wonder how it
suddenly means something different or bad. The maintenance issues *have*
been balanced against the benfits of dynamic linking, and in the most common
cases, dynamic linking won. That bloody stain on the floor was a horse, but
it was beaten to a pulp years ago and has since decayed and seeped deep into
the concrete. The smell still comes back to haunt us in threads like these.

You should, in all honesty, count your lucky stars that you still have the
ability to link programs statically -- and that people have been trying Hard
to keep static linking in mind when introducing abstraction frameworks.
After all, it's nearly impossible to do anything particularly complex (in
the "general-purpose OS" sense) on Solaris or Linux in a statically linked
world, but NetBSD has been rather good about keeping that ability intact.

Now, what you should be doing, rather than twisting the meaning out of my
words and falsely insinuating deception like a two-bit fascist political
shill[*], is opening your mind a little. Or, to put it more bluntly:
Times change; get with the program, or shut the %#@* up already. We're both
giving everyone a headache, and I'm tired of contributing to it.
(Fortunately, those with commit privileges tend to stay more level-headed.)

I give up on this thread. "You win." I've moved the lists to Bcc:, to end
it here.

==

[*] Ann Coulter would be a good example. Come to think of it, your writing
style is very similar to hers.
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Bill Studenmund
2003-09-15 03:53:40 UTC
Permalink
Post by Greg A. Woods
[ On Sunday, September 14, 2003 at 10:52:25 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
One of the major features of using PAM is API compatibility with
PAM-using applications (of which there are many, especially compared to
BSD Auth).
That answer simply does not have anything whatsoever to do with my
original statement.
In fact on the contrary you are now simply confirming the reason for
using a shim or wrapper API, especially a two-way one as I suggested, in
the first place -- i.e. an API which includes both BSD Auth client
functions and PAM client functions and which can be configured (at
runtime or at compile time) to call either framework out the back end.
Such a shim or wrapper API actually makes it better for everyone since
with any application would use either framework without (as much)
porting effort regardless of which client API it might support best
natively.
I started to look at such a shim API, but have not gotten very far. It
looks like just using PAM and having a BSD Auth using module ship in the
base system would be the best way to go.

Take care,

Bill
Alan Barrett
2003-09-15 07:59:56 UTC
Permalink
Post by Bill Studenmund
I started to look at such a shim API, but have not gotten very far.
I would like to see such a shim, but I am not competent to design it.
What I would like from it is:

* applications that use the PAM API just work;
* applications that use the BSD-Auth API just work;
* both kinds of applications get redirected to some kind of middle
layer that consults a config file to decide what to do;
* the middle layer does whatever magic is necessary to allow an
application that thinks it is using BSD-Auth to really use PAM, and
vice versa.
Post by Bill Studenmund
It looks like just using PAM and having a BSD Auth using module ship
in the base system would be the best way to go.
The people who hate dynamic linking would hate this, unless there was a
way to staticly link some subset of PAM. The people who hate PAM might
be pacified if there was a way to say "the only PAM module that is ever
allowed to run is the BSD-Auth-over-PAM proxy, and that must be staticly
linked".

--apb (Alan Barrett)
Jason Thorpe
2003-09-15 15:07:20 UTC
Permalink
Post by Alan Barrett
The people who hate dynamic linking would hate this, unless there was a
way to staticly link some subset of PAM. The people who hate PAM might
be pacified if there was a way to say "the only PAM module that is ever
allowed to run is the BSD-Auth-over-PAM proxy, and that must be staticly
linked".
My response to this is "so bloody what?"

I personally have little patience for the "anti dynamic linking" crowd,
and whenever they mention their hate of dynamic linking, it tends to
make me discount their other arguments as simply a ruse to further
their war against dynamic linking.

On the other hand, your argument here also makes the point that others
(including me) have been making for a while now, which is that is that
BSD Auth can be implemented using PAM as the application API.
Therefore, there is no need to provide any other "shim" APIs; the PAM
API serves the purpose.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-15 20:00:57 UTC
Permalink
[ On Monday, September 15, 2003 at 08:07:20 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
My response to this is "so bloody what?"
You obviously haven't been paying any attention whatsoever to either any
hard technical arguments or to any direct requests from any one of a
number of NetBSD users. You're not answering any technical questions
that remain un-answered and you seem to have made up your mind without
any outside consideration. Why are you even bothering to respond here?
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-16 01:41:04 UTC
Permalink
Post by Greg A. Woods
any outside consideration. Why are you even bothering to respond here?
Yah, good question, because your arguments are unlikely to persuade me
in any case :-)

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-15 15:41:57 UTC
Permalink
[ On Sunday, September 14, 2003 at 20:53:40 (-0700), Bill Studenmund wrote: ]
Subject: Re: BSD auth for NetBSD
I started to look at such a shim API, but have not gotten very far.
Any hints as to why not?
It
looks like just using PAM and having a BSD Auth using module ship in the
base system would be the best way to go.
That doesn't solve _any_ of the problems BSD Auth solves nor does it
even provide the BSD Auth client API (which, IIUC, was Peter's minimum
requirement). I.e. it's a slam in the face of everything BSD Auth
stands for. It's also an unfair choice since it would seem to be
ignoring all the true technical merits and be based on perceived market
share alone. What a sham, especially for an open source system that
purports to have only the highest of technical and quality standards.
I.e. you're going backwards here again Bill, not forwards.

The only really ideal solution is to provide both APIs as a shim for
each other's framework with something like nsswitch in between them so
that the administrator can choose which framework to use in production.
If you've encountered technical stumbling blocks in trying to implement
such an API then let's hear them (though perhaps in a new thread)!

An alternate solution is to evaluate each API fairly on its technical
merits _alone and choose the best one. That one client API can then be
used as a wrapper around both frameworks. It would seem adapting to the
client API is much easier for applications to do than it is to force
admins and third party vendors to compromise on which framework to
choose. I don't mind using the technically best client API (I'm a
programmer too!), so long as I am also allowed to choose to use the
authentication framework I believe to be safer and more sound for my
uses, and so long as I can continue to build static-linked systems using
BSD Auth. This means a bit more work for pkgsrc developers, but
hopefully only for the first porting effort (which can be done over time
since of course the existing crypt() and krb5 APIs remain) and from
there the original maintainers take back the patches. I'm obviously
hedging my bets on which API is technically superior, but that's a risk
I'm willing to take. (Especially since it would only be a matter of
time before the other API could be added to the shim as well. :-)

I suppose one final alternate solution could be chosen as well, and it's
not much different than we have now for certain things in the tree. It
is to provide each framework and API as separate but fully supported OS
components, with #ifdefs (or even big runtime 'if' statements and some
common configuration attribute in something like login.conf) in each
base-OS program so that it can be compiled and/or configured to use
either client API and thus either framework. This will force third
party applications to either do the same or to choose which to use (and
thus will force admins to choose either a specific set of add-on
applications). I think this would keep everyone happy enough, though
it's obviously less ideal than a shim API. Someone would either have to
flip a coin as to which was distributed in binaries, but then again with
our modern fast cross-compile systems maybe a set of binaries for each
could be offered.


Note that all of these choices are possible down the road if BSD Auth is
brought into the system first, now.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Todd Vierling
2003-09-13 18:20:23 UTC
Permalink
On Sat, 13 Sep 2003, Roland Dowdeswell wrote:

: That is what PAM and BSD Auth are, wrapper APIs around things that
: do authentication. I was suggesting that it is going overboard to
: put a wrapper around two wrappers which will surely end up having
: the compromises of both systems.
From this POV, and given the rather simplified authentication system used by
BSD Auth, it should (in SMOP theory) be pretty simple to make a PAM module
that simply defers to BSD-Auth and use it where appropriate.

(It's not possible to do PAM inside of BSD Auth, but it should be possible
to do the converse.)
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Jason Thorpe
2003-09-13 07:03:21 UTC
Permalink
On Friday, September 12, 2003, at 10:40 PM, Jun-ichiro itojun Hagino
we could introduce PAM and BSD auth into the system independently,
and let apps chose which to use (or build time option
USE_PAM/BSDAUTH).
It doesn't seem like that would really work out in the long-term, since
really, an application basically needs to use one or the other.

-- Jason R. Thorpe <***@wasabisystems.com>
Jason Thorpe
2003-09-13 01:47:38 UTC
Permalink
Post by Greg A. Woods
People say they want AFS support and that they currently use PAM on
(pick-your-favourite-commercial-OS-or-linux) to make it work, but yet
AFS can quite easily be integrated into a system using BSD Auth with
only a slight modification to the existing mechanisms for registering
AFS credentials for a process group.
You claim it is "only a slight modification", but you have provided no
technical specifics on how it would be implemented. Do you really know
how difficult it is (or isn't)?

Note I don't know the answer to that myself ... but I also don't want a
simple dismissive "oh, it'll be easy" when, in fact, it might be quite
hard.

-- Jason R. Thorpe <***@wasabisystems.com>
Greg A. Woods
2003-09-13 05:58:39 UTC
Permalink
[ On Friday, September 12, 2003 at 18:47:38 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for NetBSD
You claim it is "only a slight modification", but you have provided no
technical specifics on how it would be implemented. Do you really know
how difficult it is (or isn't)?
I believe I do know the level of difficulty, and even if I understand it
only minimally then indeed it isn't very difficult at all.

The overall the process is still identical to the way AFS authorization
works today. All we're doing is telling the kernel to create the
initial Process Authentication Group (PAG) for a different process than
the caller. I.e. we're either modifying setpag(2) to take a PID
parameter, or we're creating a variant called something like
setpag_parent(2). We're not creating a PAG and then assigning it to
some other process so there's no chance for abuse by the superuser.

If I'm not mistaken OpenAFS may already have all the necessary features
since its klog(1) program already has a "-setpag" option which can be
used on systems which don't have an AFS-ified login(1) and which creates
a new PAG for its parent process (replacing any existing PAG). The
documentation states:

The difference between the two commands is that the klog command
replaces the PAG associated with the current command shell and
tokens. The pagsh command initializes a new command shell before
creating a new PAG.

The only other useful trick might be to automatically also assign the
new PAG to any direct child processes of the new owner process which
don't already have their own uniqe PAG already assigned. This would
allow the BSD Auth authenticator program to then also authenticate the
user to his default cell, assuming the user's password for that cell is
the same as his login password. I.e. the authenticator could call "klog
-password secret" on behalf of the user. Since this trick would give
the authenticator program the same PAG as the caller then the token
obtained from a successful authentication would be associated with the
user's new PAG thus saving one more step for the user and also making it
automatic for even an AFS-naive server such as the native "ftpd" to be
potentially automatically logged into the default home AFS cell for the
system (this assumes the user's system password and default home cell
password are the same, but I bet they are in many cases anyway! ;-).

Including the change to also move the credentials pointers from the
groups list to a separate field in struct ucred is obviously more work,
but I expect it would be mostly "mechanical" work, and I think it would
make the internal interface to AFS ever so much more clear and easy to
understand and follow, at least for anyone starting at struct proc. If
I'm not mistaken the main body of AFS already uses a generic function to
request the credentials of a process so the porting effort to reflect
such a change in the kernel interface is localized to one place.
Regardless this part of it is orthogonal to the modification necessary
to create a new PAG for one's parent process.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Jason Thorpe
2003-09-13 07:07:49 UTC
Permalink
[I believe I do know the level of difficulty, and even if I understand
it
only minimally then indeed it isn't very difficult at all.
The overall the process is still identical to the way AFS authorization
works today. All we're doing is telling the kernel to create the
initial Process Authentication Group (PAG) for a different process than
the caller. I.e. we're either modifying setpag(2) to take a PID
parameter, or we're creating a variant called something like
setpag_parent(2). We're not creating a PAG and then assigning it to
some other process so there's no chance for abuse by the superuser.
But you've over-simplified the problem. Sure, you're suggesting a
solution for this *one specific case*. But you are NOT solving the
general problem, which is that BSD Auth is fundamentally incapable of
modifying the context of the process requesting the authentication,
which is a capability that is sometimes necessary and which PAM has.

-- Jason R. Thorpe <***@wasabisystems.com>
Alan Barrett
2003-09-13 09:19:00 UTC
Permalink
Let me introduce some definitions:

existing-BSD-Auth: BSD-Auth as it exists today.
extended-BSD-Auth: BSD-Auth as it could be extended in future.
unrestricted-PAM: PAM in which the module has unrestricted access to
the context of the requesting process. (For example, PAM as it
exists today, implemented using dynamic loading.)
restricted-PAM: PAM in which the module is allowed to do some things
to the context of the requesting process, but is not allowed
to do other things. (This does not exist today, but could
conceivably be implemented in future.)
unrestricted-BSD-Auth: BSD-Auth in which the module has unrestricted
access to the context of the requesting process. (This does not
exist today, and cannot reasonably be implemented in future.)
restricted-BSD-Auth: BSD-Auth in which the module is allowed to do
some things to the context of the requesting process, but is
not allowed to do other things. (Both existing-BSD-Auth and
extended-BSD-Auth are in this class.)
But you are NOT solving the general problem, which is that BSD Auth
is fundamentally incapable of modifying the context of the process
requesting the authentication, which is a capability that is sometimes
necessary and which PAM has.
It's true that unrestricted-BSD-Auth does not exist, and that
unrestricted-PAM cannot be implemented on top of restricted-BSD-Auth.

However, a BSD-Auth-like mechanism *is* capable of making any
modifications of any kind that is planned for in advance. This
is a feature, not a bug. Some kinds of modifications are
already accommodated by existing-BSD-Auth (for example, setting
environment variables). New types of modifications can be added to
extended-BSD-Auth, with amount of trouble (this is the "planning in
advance" mentioned above): you have to add a new message type to the
protocol spoken over file descriptor 3, and you might have to add new
syscalls to help pass credentials from one process to another.

restricted-PAM could be implemented over restricted-BSD-Auth, and I
suspect that that would be good enough for all but the most experimental
purposes. Whenever you discover a new kind of modification that you
wish you could make to the calling process (but that you cannot yet
make), you:

a) Add a new message format to the protocol that BSD Auth talks on
file descriptor 3;
b) If necessary, add new syscalls to deal with the data that will
appear in the new messages;
c) Add code in the BSD Auth library (which runs in the parent process)
to parse and act on the new message;
d) Add code in the PAM-over-BSD-Auth proxy to detect whether a PAM
module has made the new change that you wish to allow, and if so,
print a new message over file descriptor 3;
e) Re-link all applications that care. They were probably dynamically
linked against the BSD Auth library, so simply installing a new
version of the library (which was updated in step c above) will
probably be sufficient.

I don't know enough about AFS to tell how difficult the above steps
would be, but surely they would be *possible*? I can't tell whether the
people saying "AFS can't work over BSD Auth" mean "AFS can't work over
existing-BSD-Auth", or "AFS can't work over extended-BSD-Auth unless you
add new syscalls", or "AFS can't work over extended-BSD-Auth at all, not
even if you add new syscalls". (Similarly for smart cards instead of
AFS.)

It seems to me that it's a security risk that a partially-trusted PAM
module (for which source code might not be available) is allowed to
scribble all over the address space of the requesting process. Even in
a pure PAM world, without any BSD Auth, it would be useful to isolate
partially-trusted PAM modules behind a {restricted-PAM}-over-PAM proxy.
The proxy could run in a new process, let the partially-trusted module
do whatever it wants, and then the proxy could figure out which of the
things that are allowed to change have actually changed, and propagate
the changes back to the parent through a pipe.

A {restricted-PAM}-over-PAM proxy would look a lot like a
{restricted-PAM}-over-{BSD-Auth} proxy. They might as well use the same
child-to-parent protocol (an extended-BSD-Auth protocol), and the child
part of the proxy might not even know whether its parent was being used
in a PAM or BSD-Auth environment.

--apb (Alan Barrett)
Greg A. Woods
2003-09-13 17:23:02 UTC
Permalink
[ On Saturday, September 13, 2003 at 00:07:49 (-0700), Jason Thorpe wrote: ]
Subject: Re: BSD auth for AFS
But you've over-simplified the problem. Sure, you're suggesting a
solution for this *one specific case*. But you are NOT solving the
general problem, which is that BSD Auth is fundamentally incapable of
modifying the context of the process requesting the authentication,
which is a capability that is sometimes necessary and which PAM has.
I've not solved the problem because I don't want to. In fact by
definition and by design I _must_ NOT sovle that problem. It really is
a feature of BSD Auth to force the authenticator to run in a separate
context. It's a "VERY Good Thing(tm)"! Solving that problem would take
away the major distinguishing feature of BSD Auth (and the one I believe
primarily responsible for it being so clean, simple, small, and elegant).

Besides, anything that must be done to the caller's process context (or
address space), _can_ be done, _but_ it MUST be done in a controlled way
by proxy of the BSD Auth interface. That's the whole idea.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Roland Dowdeswell
2003-09-13 04:18:21 UTC
Permalink
On 1063417060 seconds since the Beginning of the UNIX epoch
"Greg A. Woods" wrote:
[ talking about PAM ]
Post by Greg A. Woods
themselves). It would also make it impossible to build a static-linked
NetBSD system (and especially one that used BSD Auth authenticators) (at
Have you read the [Linux] PAM code? I took a quick glance at it
and it looks surprisingly like there is support for building it
statically.

--
Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Todd Vierling
2003-09-13 00:19:39 UTC
Permalink
On Fri, 12 Sep 2003, Greg A. Woods wrote:

: > That rather defeats the purpose of PAM. Some authenticators (two-way smart
: > cards are a common example) are *stateful* and cannot run outside the
: > authenticated process without significant authenticator-specific context
: > copy operations.
:
: What stateful operations take place during (or at the end of) a session?

You have some research to do. We might as well end the discussion of the
internals here, and you can come back after reading the PAM client API.

: Sounds like a pretty broken design for something that's just supposed to
: authenticate a user so that processes can be authorized to be run as the
: UID that represents that user.

That's not the only thing PAM does. A "session" (i.e. login to logout) is
not the only encapsulating body for an authentication token.

You should note, Greg, that I personally don't like or use PAM, for similar
reasons to those you have mentioned. But certainly, given that it is
module-based, it wouldn't be unreasonable to desire NetBSD to have it as an
optionally loaded subsystem. "Don't use it if you don't want it."

Now, I have had occasion and necessity to use it in process control systems
at a semiconductor manufacturer. As a result, I do understand some of its
strong points, particularly how it's not just a "session" authentication
system. BSD Auth, however, *is* just a login session based authenticator.

In either case, the angle you're coming from is login session
authentication. This is something that need be neither of the BSD Auth nor
PAM APIs; that is why nsswitch exists. It's true that nsswitch as
implemented today isn't enough for either of BSD Auth or PAM, but it's the
perfect place to implement a way to get to either (...or the internal
authenticators).
--
-- Todd Vierling <***@duh.org> <***@pobox.com>
Greg A. Woods
2003-09-14 19:12:00 UTC
Permalink
[[ I think it may still be worthwhile returning to the questions posed
here in this now somewhat dated post.... ]]

[ On Friday, September 12, 2003 at 20:19:39 (-0400), Todd Vierling wrote: ]
Subject: Re: BSD auth for NetBSD
You have some research to do. We might as well end the discussion of the
internals here, and you can come back after reading the PAM client API.
I already knew how that PAM client API worked. It's pretty obvious if
one reads the code of login.c in FreeBSD, for example. Note how similar
the BSD Auth client API is by reading the code in login.c from OpenBSD.

I didn't ask you about generics about the API -- I asked you for
specifics about the authentication mechanism(s) you suggested might need
to exchange ongoing information during the length of the authenticated
seesion.
That's not the only thing PAM does. A "session" (i.e. login to logout) is
not the only encapsulating body for an authentication token.
Well, if you consider a session to be only something tied to a TTY, then
yes, OK, you're right. (I don't assume a session is tied to a TTY.)
Now, I have had occasion and necessity to use it in process control systems
at a semiconductor manufacturer. As a result, I do understand some of its
strong points, particularly how it's not just a "session" authentication
system. BSD Auth, however, *is* just a login session based authenticator.
BSD Auth can be used for things other than "login sessions" too you
know.

As I've already hinted several times now BSD Auth's client API could
relatively trivially be modified to require the caller not close the
auth session until the session ends (which would indeed help by
providing some way to call k5destroy() at session end).

I believe BSD Auth could even support having an instance of the
authenticator run for the duration of the session, though I'm still not
sure what the point would be.
In either case, the angle you're coming from is login session
authentication.
Actually I'm not, but "whatever".
This is something that need be neither of the BSD Auth nor
PAM APIs; that is why nsswitch exists. It's true that nsswitch as
implemented today isn't enough for either of BSD Auth or PAM, but it's the
perfect place to implement a way to get to either (...or the internal
authenticators).
Now I think we're back on more or less the same page.
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Greg A. Woods
2003-09-13 06:03:46 UTC
Permalink
[ On Saturday, September 13, 2003 at 00:18:21 (-0400), Roland Dowdeswell wrote: ]
Subject: Re: BSD auth for NetBSD
Have you read the [Linux] PAM code? I took a quick glance at it
and it looks surprisingly like there is support for building it
statically.
Last time I tried looking at the Linux PAM code I got queasy and I
quickly reverted to looking at the FreeBSD PAM code! ;-)

I'm not entirely surprised that support for static linking might be
making its way into Linux-land given the rate Linux is being adopted
into more embedded systems projects.

I am somewhat pleasantly surprised to hear this though. :-)
--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
Continue reading on narkive:
Loading...