David Maxwell wrote:
> 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?'.

The odds of it being exploitable, is for the writer of the module to
care, as long as you tell the module writer what the possible problems
are, and if you minimize such number of problems. How does a more
complex API help? So the user can make more mistakes writing a module?
Doesn't make any sense.

> 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.

This isn't what we're talking about here. We're not talking about junk
thrown by default by RedHat. We're talking about authentication
frameworks, and the learning curve required for these frameworks. Stay
on course, please.

The system will be less secure when the modules will be harder to write.
It's easier to make a bug when you need to write more code, and when
code is going to be more complex. This is, very well understood indeed.

> 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.

Please. Simple modules will result in less bugs, and more secure code,
not less.

> > 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.

The end-user decides what to do with his/her system, thanks. You won't
stop them from writing a module, even if they're a beginner. What you
will do with a more complex framework though, is make it harder for them
to write better modules, and easier to make bugs, including security bugs.

> > 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.

RTFM: http://cr.yp.to/checkpwd/interface.html. Not three processes, one
process. Did I ever mention fork()? No. It's exec().

> 
> 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?

RTFM: http://cr.yp.to/checkpwd/interface.html

> 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.

Again it's exec(), not fork(). One process only.