On Mon, Jan 27, 2003 at 04:07:44PM -0500, Dan Melomedman wrote:
> David Maxwell wrote:
> > Discussions of 'how hard/easy it is to implement an authentication
> > module' are not that interesting, for a couple of reasons (IMO).
> > 
> > (1) Far more people will use, than implement, modules - regardless of how
> > easy it is. (CAD/CAM has made Automotive implementation easier than ever
> > before - how many people design cars, and how many drive them?)
> 
> Authentication frameworks are not only meant for programmers, they're
> there for system administrators, and programmers not directly involved
> with the OS project.

Sure. I expect system administrators to _configure_ authentication
methods. I don't expect them to write them. If you say 'But it's so
easy, I can write a perl authenticator', I'll say 'what are the odds
it's exploitable?'.

> > (2) I don't necessarily see advantages in making it easy for
> > nieve/incompetent programmers to implement security sensitive portions
> > of a system, like Authentication. Having a high barrier to entry might
> > be an advantage.
> 
> So you would rather make it harder for everyone to use just because you
> feel systems will be more secure when the learning curve is steep?

Security vs. ease of use is a well understood tradeoff.

Many Linux distributions install lots of junk by default. That lowers
the learning curve, since you don't have to figure out how to install it
yourself. The system is less secure because (a) things are running
needlessly (b) things are running that the admin doesn't know about.

Having a high learning curve in general doesn't guarantee a more secure
system. Having a low learning curve to write security sensitive
functions probably will guarantee there will be more vulnerable systems
out there.

> Hand-holding isn't NetBSD's goal, as far as I know. High barriers to entry
> are concerns of commercial entities who're fighting for market share.

Not exclusively true. 

> Making writing modules easy for system administrators, and competent or 
> beginner programmers benefits administrators, and programmers. Having a high
> barrier to entry benefits consulting companies only, and hurts everybody else.
> Additionaly, less code needed means less bugs.

I don't want authentication code written by 'beginner programmers',
thanks.

> > I would say the opposite - in a security context, getting the process
> > model right (securely) is hard - because you have do deal with I/O,
> > uid/gid, access rights, and content parsing, for example, which you
> > wouldn't have to deal with in a function called in a library.
> 
> What is so hard about writing to the pipe in the preauthenticator process,
> execing the authenticator, and reading the pipe in the authenticator process?

Three processes now? That seems like a lot of context switch overhead...
anyway - I was talking about the module implementation.

I pass you a username/password through the pipe - what are the odds you
don't parse it correctly, and are subject to a buffer overflow?

I pass you a username/password as function arguments. You don't have to
parse it.

> > Making a library might require a slightly more complex Makefile, but
> > really isn't that much harder than compiling a standalone app.
> 
> We're not only talking about libraries here. We're talking about
> unnecessarily complex frameworks and APIs. PAM is built around shared
> libraries as modules, checkpassword and BSD Auth is built around the process
> model.

Okay, you've stated a point about the difference between the two. I
don't see any explanation of why (in this context) a three process team
with pipes is simpler (or better) than a function call into a shared
library.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville