What's the API for MD5 encryption?

[bolta...@boltar.world]

The Linux system I'm working on is using MD5 encryption for /etc/shadow.
None of the standard crypt() functions seem to support MD5 according to
the man pages so what API call(s) will the login package be using or is it
all bespoke code?

Thanks for any help

B2003

[Richard Kettlewell]

bolta...@boltar.world writes:
> The Linux system I'm working on is using MD5 encryption for
> /etc/shadow. None of the standard crypt() functions seem to support
> MD5 according to the man pages so what API call(s) will the login
> package be using or is it all bespoke code?

Glibc's crypt(3) supports it (or at least, it usually does); see the end
of http://www.kernel.org/doc/man-pages/online/pages/man3/crypt.3.html
for details.

--
http://www.greenend.org.uk/rjk/

[bolta...@boltar.world]

Thanks

B2003

[Nobody]

On Tue, 28 Aug 2012 13:16:44 +0000, boltar2003 wrote:

> The Linux system I'm working on is using MD5 encryption for /etc/shadow.
> None of the standard crypt() functions seem to support MD5 according to
> the man pages so what API call(s) will the login package be using or is it
> all bespoke code?

Systems which support MD5 (etc) passwords normally do so via extensions to
the crypt() function. My crypt(3) manpage looks like this one, which
documents the glibc extensions:

http://www.kernel.org/doc/man-pages/online/pages/man3/crypt.3.html

However: if you're authenticating users on Linux, you should use PAM. This
will use whichever authentication mechanisms have been configured for the
system (passwords, hardware tokens, etc), as well as implementing any
configured restrictions (e.g. only logging in from specific terminals or
networks, or during specific time periods) and/or configuring the users
environment (e.g. setting resource limits). The only code which should be
using crypt() directly is the pam_unix module (which implements
authentication via getpw*() and crypt()).

[bolta...@boltar.world]

On Tue, 28 Aug 2012 15:01:16 +0100
Nobody <nob...@nowhere.com> wrote:
>However: if you're authenticating users on Linux, you should use PAM. This

Thankful the system I'm working on (Slackware) doesn't use that over
engineered dogs dinner.

B2003

[Jorgen Grahn]

Ok, but that means you have even more opportunities to make fatal
security design errors. (Assuming you *are* going to authenticate
users.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[bolta...@boltar.world]

On 28 Aug 2012 14:51:12 GMT

Jorgen Grahn <grahn...@snipabacken.se> wrote:
>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>> On Tue, 28 Aug 2012 15:01:16 +0100
>> Nobody <nob...@nowhere.com> wrote:
>>>However: if you're authenticating users on Linux, you should use PAM. This
>>
>> Thankful the system I'm working on (Slackware) doesn't use that over
>> engineered dogs dinner.
>
>Ok, but that means you have even more opportunities to make fatal
>security design errors. (Assuming you *are* going to authenticate

Either the password they enter is correct or it isn't. If it is the program
changes its uid+group to the users else it exits. I fail to see where that can
go wrong from a design point of view.

B2003

[Eric Sosman]

I be thy Chief Security Officer, and I ope my lips to say:
"Woe be unto thee and thine, for our systems have been breached
by a Sneaky Social Engineer who tricked an authorized user into
disclosing his password. Strong though the password was, once
revealed its strength faded as that of the camel's broken back
in the eye of the needle."

And again I say to thee that thou mayest hear: "Woe be unto
thee and thine, for thou hast disobeyed Directive Delta. In our
wisdom we foresaw the Sneaky Social Engineer and knew that the
strength of the unaided password is as that of the butterfly rolling
a rock uphill, so we proclaimed Directive Delta to require Two-
Factor Authentication for all our systems. All systems but thine and
thine alone implemented Directive Delta with but a few simple config
file changes, yet thou hadst engineered thyself out of that solution."

And yet again I say unto thee that thou may heed and attend:
"Woe be unto thee and thine, for the Sneaky Social Engineer hath
entered in unto our Data Center through the unsecured portal that
thou madest in thy folly. And the Press has learned thereof, and
makes mock of us, and a legion of large clients threaten to take
their accounts elsewhere unless we offer up unto them a sacrifice,
yea, as the GOP Convention was sacrificed to Isaac."

And for the last time I ope my lips to thee and pronounce thus,
that you may ponder my words in your heart: "Woe be unto thee and
thine, for thou hast five minutes to empty thy desk and get ye gone."

--
Eric Sosman
eso...@ieee-dot-org.invalid

[William Ahern]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Tue, 2012-08-28, bolta...@boltar.world wrote:
> > On Tue, 28 Aug 2012 15:01:16 +0100
> > Nobody <nob...@nowhere.com> wrote:
> >>However: if you're authenticating users on Linux, you should use PAM. This
> >
> > Thankful the system I'm working on (Slackware) doesn't use that over
> > engineered dogs dinner.

> Ok, but that means you have even more opportunities to make fatal
> security design errors. (Assuming you *are* going to authenticate
> users.)

You mean fatal design errors like PAM? ;)

For a nice, modular, privilege separated authentication system, the OP might
want to examine BSD Auth. It'd be relatively easy to replicate on Linux, or
to point the way to a different approach altogether.

PAM is fundamentally broken, IMHO, without another layer to paper over the
issues with an authentication system built on C modules dynamically loaded
by the authenticating agent.

[Jorgen Grahn]

On Tue, 2012-08-28, bolta...@boltar.world wrote:
> On 28 Aug 2012 14:51:12 GMT
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>>> On Tue, 28 Aug 2012 15:01:16 +0100
>>> Nobody <nob...@nowhere.com> wrote:
>>>>However: if you're authenticating users on Linux, you should use PAM. This
>>>
>>> Thankful the system I'm working on (Slackware) doesn't use that over
>>> engineered dogs dinner.
>>
>>Ok, but that means you have even more opportunities to make fatal
>>security design errors. (Assuming you *are* going to authenticate
>
> Either the password they enter is correct or it isn't. If it is the program
> changes its uid+group to the users else it exits.
> I fail to see where that can
> go wrong from a design point of view.

I know next-to-nothing about these things, but your apparent lack of
humility worries me. Security is *hard*.

[Rainer Weikusat]

A cursory search on that basically yielded that "PAM is fundamentally
broken" is identical to "It doesn't contain enough voodoo code
supposed to deal with 'the unknown programming error which never
occurs in the privileged code of OUR system'" to please (some of) the
OpenBSD developers. IMO, people who come up with all kinds of
contrived programming obstacles based on the assumption that these
might be able to mitigate the effects of 'the unknown programming
error which never occurs in the privileged code of OUR system' are
'fundamentally broken' --- they are apparently incapable of
understanding that the problem "I'm afraid of this huge mass of
existing code I don't fully understand" cannot be solved by "Let's add
some code!" (no, I don't believe in privilege separation based
trusting the kernel blindly because there's no other choice than to
trust that. Either the people implementing it have some kind of magic
wand which causes the kernel and their code to be free of security
problems. In this case, they could as well apply it to the untrusted
code and do away with the need for this mechanism. Or they don't. And
then, their code is as suspect as any other code and their energies
would be better spent on fixing real problems instead of trying to
work around hypothetical ones).

So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
of relief)' what are the specific problems with PAM?

[William Ahern]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:
<snip>

> A cursory search on that basically yielded that "PAM is fundamentally
> broken" is identical to "It doesn't contain enough voodoo code
> supposed to deal with 'the unknown programming error which never
> occurs in the privileged code of OUR system'" to please (some of) the
> OpenBSD developers. IMO, people who come up with all kinds of
> contrived programming obstacles based on the assumption that these
> might be able to mitigate the effects of 'the unknown programming
> error which never occurs in the privileged code of OUR system' are
> 'fundamentally broken' --- they are apparently incapable of
> understanding that the problem "I'm afraid of this huge mass of
> existing code I don't fully understand" cannot be solved by "Let's add
> some code!" (no, I don't believe in privilege separation based
> trusting the kernel blindly because there's no other choice than to
> trust that. Either the people implementing it have some kind of magic
> wand which causes the kernel and their code to be free of security
> problems. In this case, they could as well apply it to the untrusted
> code and do away with the need for this mechanism. Or they don't. And
> then, their code is as suspect as any other code and their energies
> would be better spent on fixing real problems instead of trying to
> work around hypothetical ones).

OpenBSD is probably the last project I would think of when worrying about
distributions which rely on added code and tricks at the expense of vetting
and fixing bugs in the core.

BSD Auth isn't a layer over PAM. It's a completely different and much
simpler design. OpenBSD never had PAM, and adopted BSD Auth from BSD/OS.

Privilege separation was authentication is a no brainer, and any
authentication architecture which doesn't provide this out-of-the-box for
usercode is broken, IMNSHO.

For BSD Auth, you basically add your authenticating app to the `auth' group
to acquire access to /usr/libexec/auth. Some authentication modules are
setuid root, others setgid auth, and the remainder setuid or setgid to
something else entirely. The modules speak a simple protocol over
stdin/stdout.

It's small, simple, and provides far less opportunity for exploitation than
PAM because the authenticating application never has root privileges, just a
pipe to a privileged module.

From the C perspective, you usually just use an idiom like:

if (auth_userokay(name, style, type, password)) {
...
} else {
...
}

There's a slightly more verbose API if the app can handle challenge/response
authentication.

Adding a new authentication method is as simple as dropping a new program
into the directory.

> So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
> of relief)' what are the specific problems with PAM?

Minus the problems you seem to have rejected as invalid out-of-hand, I guess
none, then.

[bolta...@boltar.world]

On 28 Aug 2012 19:10:59 GMT

Jorgen Grahn <grahn...@snipabacken.se> wrote:
>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>> On 28 Aug 2012 14:51:12 GMT
>> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>>>> On Tue, 28 Aug 2012 15:01:16 +0100
>>>> Nobody <nob...@nowhere.com> wrote:
>>>>>However: if you're authenticating users on Linux, you should use PAM. This
>>>>
>>>> Thankful the system I'm working on (Slackware) doesn't use that over
>>>> engineered dogs dinner.
>>>
>>>Ok, but that means you have even more opportunities to make fatal
>>>security design errors. (Assuming you *are* going to authenticate
>>
>> Either the password they enter is correct or it isn't. If it is the program
>> changes its uid+group to the users else it exits.
>> I fail to see where that can
>> go wrong from a design point of view.
>
>I know next-to-nothing about these things, but your apparent lack of
>humility worries me. Security is *hard*.

Where does humility come into it? I'm using a tried and trusted design.
If you have an issue with it complain to the designers of unix, not me.

B2003

[bolta...@boltar.world]

On Tue, 28 Aug 2012 22:26:18 +0100
Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
>of relief)' what are the specific problems with PAM?

An overcomplicated API in my opinion. Why (IIRC) do I have to call
pam_start, pam_authenticate, pam_get_item, pam_end just to find out if
a user has entered the correct password for gods sake? What idiot thought
that was a sensible API decision? It completely goes against the unix
philosphy of keeping things concise and simple.

B2003

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> <snip>
>> A cursory search on that basically yielded that "PAM is fundamentally
>> broken" is identical to "It doesn't contain enough voodoo code
>> supposed to deal with 'the unknown programming error which never
>> occurs in the privileged code of OUR system'" to please (some of) the
>> OpenBSD developers.

[...]

> OpenBSD is probably the last project I would think of when worrying about
> distributions which rely on added code and tricks at the expense of vetting
> and fixing bugs in the core.

Yet the project prides itself on the amount of 'security features'
supposed to make 'exploiting [hypothetical] bugs' 'more
difficult'. And if there's some evil magic lurking in code, where you
can never be certain that it doesn't perhaps contain another critical
error, the same evil magic must also lurk in the 'address space layout
randomization code' (random 'out of my head' example --- no X ATM),
IOW, 'more code' cannot ever increase the 'security' of the system,
especially code which makes its behaviour harder to predict and thus,
more difficult to analyze.

> BSD Auth isn't a layer over PAM. It's a completely different and much
> simpler design. OpenBSD never had PAM, and adopted BSD Auth from
> BSD/OS.

... as anyone capable of reading can easily gather even from the
fairly short Wikipedia article on this ...

> Privilege separation was authentication is a no brainer, and any
> authentication architecture which doesn't provide this out-of-the-box for
> usercode is broken, IMNSHO.

You already asserted that. The criticism above (and with a little more
detail in my original text) applies to that as well: It is supposed to
work around 'hypothetical errors' in other code. By which strange
magic did it become free of 'hypothetical errors' itself, especially
considering that it intimately rests on the assertion of "free of
hypothetical bug-ness" of a really large and complicated program all
kinds of people have worked on for some decades, namely, the kernel?

NB: There is no solution to this enigma. The approach is illogical in
itself and in the end, just boils down to the 'time-tested' 'copy
protection' approach of "Make it so complicated that they'll never
figure out how it works". Naturally, this ends at the point where it
became so complicated that the author (or set of authors) no longer
understands it. But some people on this planet are going to be more
intelligent or maybe, just more lucky.

[...]

>> So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
>> of relief)' what are the specific problems with PAM?
>
> Minus the problems you seem to have rejected as invalid out-of-hand, I guess
> none, then.

You didn't name any problems when I asked for them.

[Rainer Weikusat]

Since this is the much more interesting question, I'll sum up the 'PAM issues'
mentioned so far:

- from what I remember, the API is pretty atrocious. But I
haven't looked at it for a decade and by that time, I
considered the BSD ftpd code an horrendous
tangle. Considering some things I've been dealing with in
the meantime (eg, fetchmail or racoon) or written myself
(:-), I'd probably rather classify it as 'cute little
program'/ 'minor nuisance' nowadays

- it doesn't force people to employ 'privileged helper
processes' (there's nothing which stops anyone who so desires
to run 'the PAM operations' in this way). But this is a
means to an end and not an end in itself and to me, it seems
that it is mainly concerned with achieving theoretical
purity for the sake of itself while disregarding practical
downsides (increased complexity of the complete system)

[Jorgen Grahn]

On Wed, 2012-08-29, bolta...@boltar.world wrote:
> On 28 Aug 2012 19:10:59 GMT
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>>> On 28 Aug 2012 14:51:12 GMT
>>> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>>>On Tue, 2012-08-28, bolta...@boltar.world wrote:
>>>>> On Tue, 28 Aug 2012 15:01:16 +0100
>>>>> Nobody <nob...@nowhere.com> wrote:
>>>>>>However: if you're authenticating users on Linux, you should use PAM. This
>>>>>
>>>>> Thankful the system I'm working on (Slackware) doesn't use that over
>>>>> engineered dogs dinner.
>>>>
>>>>Ok, but that means you have even more opportunities to make fatal
>>>>security design errors. (Assuming you *are* going to authenticate
>>>
>>> Either the password they enter is correct or it isn't. If it is the program
>>> changes its uid+group to the users else it exits.
>>> I fail to see where that can
>>> go wrong from a design point of view.
>>
>>I know next-to-nothing about these things, but your apparent lack of
>>humility worries me. Security is *hard*.
>
> Where does humility come into it?

Ok, "apparent lack of paranoia", sounds better,

> I'm using a tried and trusted design.
> If you have an issue with it complain to the designers of unix, not me.

I won't try to defend PAM (not the first time I've heard people
complain about it) but don't you have a few problems to handle?
E.g. my system doesn't use MD5 but SHA-something for /etc/shadow.

[Nobody]

Which is probably why Slackware doen't really see anything beyond hobby
use nowadays.

There are many environments where password authentication just isn't good
enough (insecure, inconvenient), and/or where creating a session involves
far more than simply setting UID/GIDs then executing pw->pw_shell.

[Alan Curry]

In article <slrnk3scng.p...@frailea.sa.invalid>,

Jorgen Grahn <grahn...@snipabacken.se> wrote:
>
>I won't try to defend PAM (not the first time I've heard people
>complain about it) but don't you have a few problems to handle?
>E.g. my system doesn't use MD5 but SHA-something for /etc/shadow.

You don't need to do anything special to handle those when verifying a
password. When creating a new one, you have to generate salt of the
appropriate size and add the appropriate format tag, but verifying is just
strcmp(storedpw, crypt(givenpw, storedpw)) regardless of hash algorithm.

That's really all there is to it. One crypt(), one strcmp(), and then if
you're properly paranoid bzero the password so it doesn't stick around in
memory after you're done. PAM is a crazy amount of extra code.

--
Alan Curry

[Jorgen Grahn]

On Wed, 2012-08-29, Alan Curry wrote:
> In article <slrnk3scng.p...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>
>>I won't try to defend PAM (not the first time I've heard people
>>complain about it) but don't you have a few problems to handle?
>>E.g. my system doesn't use MD5 but SHA-something for /etc/shadow.
>
> You don't need to do anything special to handle those when verifying a
> password. When creating a new one, you have to generate salt of the
> appropriate size and add the appropriate format tag, but verifying is just
> strcmp(storedpw, crypt(givenpw, storedpw)) regardless of hash algorithm.

Ah, sorry. I fixated on the original question, and didn't notice that
crypt(3) is (to quote the man page) "the password encryption
function". I thought it was just a collection of (or wrapper for)
algorithms.

[William Ahern]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> William Ahern <wil...@wilbur.25thandClement.com> writes:
> > Rainer Weikusat <rwei...@mssgmbh.com> wrote:
<snip>

> >> So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
> >> of relief)' what are the specific problems with PAM?
> >
> > Minus the problems you seem to have rejected as invalid out-of-hand, I
> > guess none, then.

> You didn't name any problems when I asked for them.

If you think it's good design to require that a process merely verifying a
system password have euid=0, then there's nothing to discuss. Good luck with
that approach.

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> William Ahern <wil...@wilbur.25thandClement.com> writes:
>> > Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> <snip>
>> >> So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
>> >> of relief)' what are the specific problems with PAM?
>> >
>> > Minus the problems you seem to have rejected as invalid out-of-hand, I
>> > guess none, then.
>
>> You didn't name any problems when I asked for them.
>
> If you think it's good design to require that a process merely verifying a
> system password have euid=0, then there's nothing to discuss.

I was asking for *YOUR* thoughts on this, not writing about
mine. And the statement above is phantasy -- a process whose sole
privileged operation is 'verify a system password' needs the
necessary privileges to enable it to access the corresponding password
hash. For the usual, simple case this means 'having read permissions on
the password file'. What is required for that depends on the
filesystem permissions of this file, not on any particular
authentication scheme.

[William Ahern]

Nothing you're saying makes sense to me. We're discussing _particular_
schemes and _particular_ implementations. And in particular, PAM requires
euid=0 to guarantee the loaded authentication mechanism has the proper
privileges to acquire any indeterminate resource. Therefore, PAM is
deficient and defective IMO, and inferior to BSD Auth.

There are all manner of ways to hack PAM, like emulating BSD Auth by
executing external programs from a loaded mechanism, or by specifying a
fixed set of resources and mechanisms a priori which require non-root
permissions. And we could always write something from scratch and, e.g.,
employ domain sockets and SO_PEERCRED. But those options are irrelevant
regarding either someone authenticating on a typical system, or to an
appraisal of the abstract design.

[Ian Collins]

The simple case is probably the exception. Most networked systems use
something other than files for authentication.

--
Ian Collins

[Nobody]

On Thu, 30 Aug 2012 15:15:27 +1200, Ian Collins wrote:

>>> If you think it's good design to require that a process merely
>>> verifying a system password have euid=0, then there's nothing to
>>> discuss.
>>
>> I was asking for *YOUR* thoughts on this, not writing about mine. And
>> the statement above is phantasy -- a process whose sole privileged
>> operation is 'verify a system password' needs the necessary privileges
>> to enable it to access the corresponding password hash. For the usual,
>> simple case this means 'having read permissions on the password file'.
>> What is required for that depends on the filesystem permissions of this
>> file, not on any particular authentication scheme.
>
> The simple case is probably the exception. Most networked systems use
> something other than files for authentication.

That much is handled by NSS. What can't be handled by NSS are
authentication mechanisms which don't involve coughing up a password hash
(cryptographic certificates, S/KEY, Kerberos, ...).

[bolta...@boltar.world]

On Wed, 29 Aug 2012 17:36:59 +0100
Nobody <nob...@nowhere.com> wrote:
>On Tue, 28 Aug 2012 14:32:03 +0000, boltar2003 wrote:
>
>> On Tue, 28 Aug 2012 15:01:16 +0100
>> Nobody <nob...@nowhere.com> wrote:
>>>However: if you're authenticating users on Linux, you should use PAM. This
>>
>> Thankful the system I'm working on (Slackware) doesn't use that over
>> engineered dogs dinner.
>
>Which is probably why Slackware doen't really see anything beyond hobby
>use nowadays.
>
>There are many environments where password authentication just isn't good

Really? So what sort of authentication are you thinking of? Dongle? Retina
scan? Fingerprint? Can't say I've ever seen any of those used on any unix
servers I've worked on.

B2003

[Rainer Weikusat]

Ian Collins <ian-...@hotmail.com> writes:
> On 08/30/12 10:36 AM, Rainer Weikusat wrote:
>> William Ahern<wil...@wilbur.25thandClement.com> writes:

[...]

>>> If you think it's good design to require that a process merely verifying a
>>> system password have euid=0, then there's nothing to discuss.
>>
>> I was asking for *YOUR* thoughts on this, not writing about
>> mine. And the statement above is phantasy -- a process whose sole
>> privileged operation is 'verify a system password' needs the
>> necessary privileges to enable it to access the corresponding password
>> hash. For the usual, simple case this means 'having read permissions on
>> the password file'. What is required for that depends on the
>> filesystem permissions of this file, not on any particular
>> authentication scheme.
>
> The simple case is probably the exception. Most networked systems use
> something other than files for authentication.

The (possibily intentional) problem with 'blanket statements' like
your's (or William Ahern's) is that they are not really meaningful on
their own: In order to turn them into an actual example, the party who
didn't write them has to make some assumptions about the context (if
any) the original writer thought of. And this is a very inefficient
way of conducting a discussion (it may be a very efficient way to
avoid a discussion or to kill a discussion, however).

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> William Ahern <wil...@wilbur.25thandClement.com> writes:
>> > Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> >> William Ahern <wil...@wilbur.25thandClement.com> writes:
>> >> > Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> > <snip>
>> >> >> So, minus this 'API-I-thankfully-didn't-need-to-use-since-2001-(sigh
>> >> >> of relief)' what are the specific problems with PAM?
>> >> >
>> >> > Minus the problems you seem to have rejected as invalid out-of-hand, I
>> >> > guess none, then.
>> >
>> >> You didn't name any problems when I asked for them.
>> >
>> > If you think it's good design to require that a process merely verifying a
>> > system password have euid=0, then there's nothing to discuss.
>
>> I was asking for *YOUR* thoughts on this, not writing about mine. And the
>> statement above is phantasy -- a process whose sole privileged operation
>> is 'verify a system password' needs the necessary privileges to enable it
>> to access the corresponding password hash. For the usual, simple case this
>> means 'having read permissions on the password file'. What is required for
>> that depends on the filesystem permissions of this file, not on any
>> particular authentication scheme.
>
> Nothing you're saying makes sense to me.

This would imply that the ordinary UNIX(*) DAC mechanism is beyond
your understanding. By extension, this is also a statement about your
opinion about PAM :->.

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:

[...]

> And in particular, PAM requires euid=0 to guarantee the loaded
> authentication mechanism has the proper privileges to acquire any
> indeterminate resource. Therefore, PAM is deficient and defective
> IMO, and inferior to BSD Auth.
>
> There are all manner of ways to hack PAM, like emulating BSD Auth by
> executing external programs from a loaded mechanism,

And there are all manners to 'hack' BSD system authentication, such as
running the strcmp(input, crypt(...)) from a dediciated process with
'euid 0' but that still leaves you with the 'password verifying
process' running with elevated privileges, it's just a different
process. Also, since BSD Auth just requires 'adding a program', a
program doing authentication via PAM could be added. Would this now
cause PAM to become good or BSD Auth to become bad? These are really
just tangential questions. What I'm looking for is something like 'The
BSD Auth protocol can do xxx, xxx being a good thing. The PAM protocol
can't do xxx because of ...'. That would be a criticism of PAM
itself. 'The way PAM is commonly used implies ... and this is a bad
thing because of ...' would be a different question. Also, if 'because
of ...' really boils down to 'because of the hypothetical software
error' it evaporates into nothing: It should be possible to locate a
phrack edition containing an article which was roughly titled
'Exploiting BSD (or OpenBSD) kernel vulnerabilities for fun and
profit' written to mock Theo de Raadt's conviction that 'the
hypothetical software error' will only ever occur in code which
doesn't cause 'privsep' to break down. It ain't so.

[bolta...@boltar.world]

On Thu, 30 Aug 2012 11:18:11 +0100
Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>And there are all manners to 'hack' BSD system authentication, such as
>running the strcmp(input, crypt(...)) from a dediciated process with
>'euid 0' but that still leaves you with the 'password verifying

If there is an unauthorised program running as root then your system
is already hacked making the issue of decrypting user passwords moot.

B2003

[Casper H.S. Dik]

Rainer Weikusat <rwei...@mssgmbh.com> writes:

>... Also, if 'because

>of ...' really boils down to 'because of the hypothetical software
>error' it evaporates into nothing: It should be possible to locate a
>phrack edition containing an article which was roughly titled
>'Exploiting BSD (or OpenBSD) kernel vulnerabilities for fun and
>profit' written to mock Theo de Raadt's conviction that 'the
>hypothetical software error' will only ever occur in code which
>doesn't cause 'privsep' to break down. It ain't so.

I remember also some issue in OpenSSH which was *caused* by privsep.

privsep often adds more code and more code gives more
bugs and some of the bugs land on the wrong side of the
divide.

Casper

[Anonymous]

RSA pubkey auth. Passwords are magnitudes weaker..

[Rainer Weikusat]

Rainer Weikusat <rwei...@mssgmbh.com> writes:

[...]

> It should be possible to locate a phrack edition containing an
> article which was roughly titled 'Exploiting BSD (or OpenBSD) kernel
> vulnerabilities for fun and profit'

Link to that:

http://www.phrack.org/issues.html?issue=60&id=6&mode=txt

This was released on 28/12/2002 and this means that this particular
way to exploit a kernel error has meanwhile probably been 'obfuscated
away' to a serious degree and the error itself has - at least I hope
so - been fixed.

[James K. Lowden]

On Tue, 28 Aug 2012 20:35:56 -0700
William Ahern <wil...@wilbur.25thandClement.com> wrote:

> For BSD Auth, you basically add your authenticating app to the `auth'
> group to acquire access to /usr/libexec/auth. Some authentication
> modules are setuid root, others setgid auth, and the remainder setuid
> or setgid to something else entirely. The modules speak a simple
> protocol over stdin/stdout.
>
> It's small, simple, and provides far less opportunity for
> exploitation than PAM because the authenticating application never
> has root privileges, just a pipe to a privileged module.
>
> From the C perspective, you usually just use an idiom like:
>
> if (auth_userokay(name, style, type, password)) {
> ...
> } else {
> ...
> }
>
> There's a slightly more verbose API if the app can handle
> challenge/response authentication.
>
> Adding a new authentication method is as simple as dropping a new
> program into the directory.

...

> PAM is fundamentally broken, IMHO, without another layer to paper
> over the issues with an authentication system built on C modules
> dynamically loaded by the authenticating agent.

(Many thanks for that cogent description!)

On Tue, 28 Aug 2012 22:26:18 +0100

Rainer Weikusat <rwei...@mssgmbh.com> responded:

> A cursory search on that basically yielded that "PAM is fundamentally
> broken" is identical to "It doesn't contain enough voodoo code
> supposed to deal with 'the unknown programming error which never
> occurs in the privileged code of OUR system'" to please (some of) the
> OpenBSD developers. IMO, people who come up with all kinds of
> contrived programming obstacles based on the assumption that these
> might be able to mitigate the effects of 'the unknown programming
> error which never occurs in the privileged code of OUR system' are
> 'fundamentally broken' --- they are apparently incapable of
> understanding that the problem "I'm afraid of this huge mass of
> existing code I don't fully understand" cannot be solved by "Let's add
> some code!"

Rainer,

William Ahern didn't say anything about which OS he uses. The word
"hypothetical" doesn't appear in his post. He makes no reference to
unknown programming errors, nor any assertion about the quality of the
kernel.

If you're going to attack his argument, it would be more productive to
engage something he actually said.

He sums up his case this way:

> PAM requires euid=0 to guarantee the loaded authentication mechanism
> has the proper privileges to acquire any indeterminate resource.
> Therefore, PAM is deficient and defective IMO, and inferior to BSD
> Auth.

That seems pretty solid to me. If you disagree, why don't you start
there?

--jkl

[Rainer Weikusat]

"James K. Lowden" <jklo...@speakeasy.net> writes:

[...]

>> PAM requires euid=0 to guarantee the loaded authentication mechanism
>> has the proper privileges to acquire any indeterminate resource.
>> Therefore, PAM is deficient and defective IMO, and inferior to BSD
>> Auth.
>
> That seems pretty solid to me. If you disagree, why don't you start
> there?

Because I was asking him what he meant with 'PAM is fundamentally
broken'. And I'm not going to tbe drawn into a 'reverse fan war' just
to distract from the fact that nothing specifically related to PAM
came up so far.

BTW, depending on the OS in question, 'euid 0' might not be suffcient
to 'to guarantee the loaded authentication mechanism has the proper
privileges to acquire any indeterminate resource' and - also depending
on the OS and its configuration - it might not be required. And, of
course, the 'BSD authentication programs' require sufficient
privileges 'to guarantee' that they have 'the proper privileges to
acquire any indeterminate resource' as well, consequently, the
statement above is a red herring.

[William Ahern]

The following has garnered a sizeable following _outside_ of enterprise
(where RSA--the company--reigns supreme), at least compared to the public
key crypto alternatives:

http://www.yubico.com/

They sell a hash-based one-time-password (HOTP) USB key fob which appears as
a keyboard device to the client computer. When you push the button it prints
the next password, followed by a newline character. So it'll work without
any client-side software, and works seamlessly with simple web applications.

On the server side it requires special handling, but easily integrates with
PAM or BSD Auth. Yubico also sells an HSM to store and validate the secrets,
but it's a little pricey. (I received a beta version which I've been meaning
to play around with for the past year or so). Most people will just store
the shared secrets on the filesystem.

The sheer simplicitly far outweighs the issues with HOTP, IMO.

[William Ahern]

I wouldn't argue that. But with BSD Auth, the privsep is already
implemented, and it's simpler then how it works in, e.g., OpenSSH.

With PAM you have to jump through hoops to deal with the fact that you need
root privileges just to check a password. There's no such hoop jumping
required with BSD Auth.

Also, FWIW, privsep has mitigated more bugs in OpenSSH than it's created or
exacerbated. (I'll risk leaving that claim without substantiation 'cause
I've got a meeting ;)

[Nobody]

On Thu, 30 Aug 2012 08:34:56 +0000, boltar2003 wrote:

>>There are many environments where password authentication just isn't good
>
> Really? So what sort of authentication are you thinking of? Dongle? Retina
> scan? Fingerprint? Can't say I've ever seen any of those used on any unix
> servers I've worked on.

SecurID and smart cards were both fairly popular the last time I worked
in Unix sysadmin (around 6 years ago).

[bolta...@boltar.world]

On Thu, 30 Aug 2012 14:37:49 -0700
William Ahern <wil...@wilbur.25thandClement.com> wrote:
>They sell a hash-based one-time-password (HOTP) USB key fob which appears as
>a keyboard device to the client computer. When you push the button it prints

Great - until the fob is lost.

B2003

[bolta...@boltar.world]

What on earth for? Here sudo on the servers is disallowed and root can only
log in from the consoles in the server room which itself is security code
protected. Anyone who can steal a server room pass can also steal a securID
fob so it adds nothing to security , just extra admin hassle not to mention
the licensing costs.

B2003

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:
> Casper H.S. Dik <Caspe...@orspamcle.com> wrote:
>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>
>> >... Also, if 'because
>> >of ...' really boils down to 'because of the hypothetical software
>> >error' it evaporates into nothing: It should be possible to locate a
>> >phrack edition containing an article which was roughly titled
>> >'Exploiting BSD (or OpenBSD) kernel vulnerabilities for fun and
>> >profit' written to mock Theo de Raadt's conviction that 'the
>> >hypothetical software error' will only ever occur in code which
>> >doesn't cause 'privsep' to break down. It ain't so.
>
>> I remember also some issue in OpenSSH which was *caused* by privsep.
>
>> privsep often adds more code and more code gives more
>> bugs and some of the bugs land on the wrong side of the
>> divide.
>
> I wouldn't argue that. But with BSD Auth, the privsep is already
> implemented, and it's simpler then how it works in, e.g., OpenSSH.

That someone else already wrote the code is another tangential fact
and - strange how it always seems to come back to that - it is equally
true for PAM. Provided that any specific implementation of 'BSD
Authentication framework' + 'OS kernel supposed to enforce the
isolation' is free of errors with security impact, applications can
use it 'securely' but again, the exact same thing is true for
PAM. Specifically, privilege separation is supposed to mitigate yet
unknown coding errors in the applications using the mechanism and from
the application standpoint, a facility protecting the application from
yet unknown bugs in the authentication code and the kernel would seem
just as necessary. "We must do something. This is
something. Therefore, we must do it." didn't become any better as
rational justification of anything in the meantime. There's also the
issue that some programs do nothing but perform privileged operations
and consequently, this scheme doesn't even work as 'sysadmin peace of
mind' device for them. So what does 'BSD Authentication' offer for
such an application, if it actually offers anything, that PAM doesn't
offer?

NB: Remembering similar discussions from the past, I'm about to come
to the conclusion that it really doesn't offer anything than the magic
TLA and assume that we will have 'Justin Bieber authentication',
catering to a different group of fans, in future, should the guy ever
'employ his talents' in that direction.

[Nobody]

On Fri, 31 Aug 2012 09:40:18 +0000, boltar2003 wrote:

>>>>There are many environments where password authentication just isn't good
>>>
>>> Really? So what sort of authentication are you thinking of? Dongle? Retina
>>> scan? Fingerprint? Can't say I've ever seen any of those used on any unix
>>> servers I've worked on.
>>
>>SecurID and smart cards were both fairly popular the last time I worked
>>in Unix sysadmin (around 6 years ago).
>
> What on earth for? Here sudo on the servers is disallowed and root can only
> log in from the consoles in the server room which itself is security code
> protected.

Those authentication methods were used for normal users.

The "root can only log in from the consoles in the server room" is
historically implented via /etc/securetty. A program which does its
own authentication has to explicitly check /etc/securetty. Any program
which uses PAM will get this behaviour automatically (assuming that the
system-wide configuration uses the pam_securetty.so module). But
pam_access.so is more flexible, allowing you to allow/deny access to
any user or group, from IP addresses as well as ttys (requiring access
to be via console or serial tty is often inconvenient).

[Doug McIntyre]

bolta...@boltar.world writes:
>>SecurID and smart cards were both fairly popular the last time I worked
>>in Unix sysadmin (around 6 years ago).

>What on earth for? Here sudo on the servers is disallowed and root can only
>log in from the consoles in the server room which itself is security code
>protected. Anyone who can steal a server room pass can also steal a securID
>fob so it adds nothing to security , just extra admin hassle not to mention
>the licensing costs.

Many environments require accountability and logging. Ie. PCI/DSS
requires root/administrator accounts to be not used at all, and all
administrative commands to be run through either a priviledged level
unique account for each administrator, or sudo logged.

PCI/DSS and SarbOx also require two factor authorization for remote access.
The easy way to do that is with dongles, although x.509 certificates
are used as well.

When you work with multiple administrators, it is extremely useful to
have logging of what work was done when. In larger companies, this is
essential. The one lone admin can't handle it all, and knowing what
others have done last is essential.

If your computer room is in the data center across town, or accross
the country, it is pretty inconvienent to hop in the car every time
you need a change.

Also, if the secureID dongle gets lost, that doesn't provide
access. With that setup, you typically have three items. The username,
the password, and the secureID. You have to tack on the secureID
unique OTP onto the end of the password in order to get access.
Loosing the dongle gives an attacker only one piece (or maybe two if
they know the person who lost it). It does not give them all three.
Presumably, the person who lost it will report it right away and that
dongle will be disabled and audited.

[William Ahern]

IME, most unix servers are root'd from unprivileged accounts, particularly
shell accounts. Attackers break into some Windows machine and sniff
passwords, or break into some other server where they reused the same
password; log into the unix server; and then leverage any one of the myriad
local root exploits in the wild at the moment. I've seen it more times than
I can count. Most companies are clueless and don't even realize they've been
hacked until their box has been passed around--like a cheap [insert object
reference here]--to someone careless enough to leave an obvious clue.

Some unices are much, much worse than others. I got into a shouting match
with an IT manager at a corporation once, and in front of the CEO! The
manager was frustrated because I refused to use a vanilla RHES environment
for a security critical service, and he was too lazy to learn the new
system; that is, he couldn't copy+paste his commands from stack exchange--or
whatever it's equivalent was at the time. The CEO asked why I couldn't just
do what the manager wanted. I explained that the manager did what he wanted
for 3 years and was root'd twice, unnoticed for months each time. Plus, that
box was a jumping off point for several other compromises. But I'd been
doing what I wanted for about 2 years without incident, and with
significantly more accounts and traffic, and without all the useless
firewalls and bologna he had set up which--in matter of fact--merely
provided an illusion of security.**

IME, all things being equal, password authentication is undesirable no
matter how locked down your box. The simple odds are such that the attacker
got onto the box using an unprivileged, non-administrator account. His M.O.
is to elevate his privileges using an exploit in the kernel or in a process
with root privileges. Firewalls or sudo rules are unlikely to make a
difference, because those are site specific.

So, I usually try to require any shell account used by a Windows users (a
self-selective bunch) to use a token or certificate. That strengthens
defenses where they're weakest--the users' machines. Everybody else usually
use tokens or certificates without my admonishment, and I keep password auth
open for their convenience.

Requiring strong passwords doesn't solve the problem, because the more
difficult the password is to remember, the more likely they're going to
reuse it on some MS Exchange server or web application; and in any event,
password sniffers on Windows boxes are just too common. In a way that's a
good thing, because that's the low hanging fruit. Unless the victim is being
trageted specifically, if they use a certificate or token the login
credentials are likely to go unnoticed by the sniffer.

Also, what's more effective than requiring strong passwords, and/or frequent
expiration, is simply stopping dictionary attacks. That's far easier to
accomplish, and avoids pissing off your users with make-work.


** I left that job, they switched back to Linux, and the inevitable
happened. And almost the exact same scenario repeated itself at another
company.

[William Ahern]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:
<snip>

> That someone else already wrote the code is another tangential fact and -
> strange how it always seems to come back to that

I mention it not because someone else wrote it, because that someone was the
vendor, and what the vendor provided is being hammered on by every user and
is a focal point for code inspection. As opposed to ad hoc privsep
implementations.

> it is equally true for PAM.

It is equally true for PAM, but not I'm criticing the code quality of PAM,
but the design decision to use loadable modules, and in particular, not to
interpose a process boundary between the authenticating agent and the
authentication mechanism. And by authenticating agent, I mean crap like a
PHP web application.

> Provided that any specific implementation of 'BSD Authentication
> framework' + 'OS kernel supposed to enforce the isolation' is free of
> errors with security impact, applications can use it 'securely' but again,
> the exact same thing is true for PAM.

Wrong. The difference is that PAM is loaded into the process. I think it's
fair to argue that an authenticating agent, like a PHP web application or
IMAP server, has far more potentially exploitable surface area than
PAM + kernel (or BSD Auth + kernel) alone.

When using PAM, attackers get to leverage bugs in PHPFoo + PAM + kernel,
whereas with BSD Auth all they have at their disposal is BSD Auth + kernel.

> Specifically, privilege separation is supposed to mitigate yet unknown
> coding errors in the applications using the mechanism and from the
> application standpoint, a facility protecting the application from yet
> unknown bugs in the authentication code and the kernel would seem just as
> necessary. "We must do something. This is something. Therefore, we must do
> it." didn't become any better as rational justification of anything in the
> meantime. There's also the issue that some programs do nothing but perform
> privileged operations and consequently, this scheme doesn't even work as
> 'sysadmin peace of mind' device for them. So what does 'BSD
> Authentication' offer for such an application, if it actually offers
> anything, that PAM doesn't offer?

Here's how I understand your argument:

a) Privsep merely protects a broken authenticating program from itself. If
the authenticating program is broken, then it doesn't matter whether it has
root privileges because

b) the attacker will just use a kernel exploit, which usually doesn't
require root privileges.

c) All kernels are exploitable.

There are so many premises I disagree with in such an argument that I've
heretofore refrained from addressing it directly. Even though, FWIW, I'll
grant you that all kernels are exploitable.

[William Ahern]

William Ahern <wil...@wilbur.25thandclement.com> wrote:
<snip>

> Some unices are much, much worse than others. I got into a shouting match
> with an IT manager at a corporation once, and in front of the CEO!

<snip>

> ** I left that job, they switched back to Linux, and the inevitable
> happened. And almost the exact same scenario repeated itself at another
> company.

To recruiters and for posterity: I left on excellent terms a year later. And
I was an engineer in a different department altogether, which is why the
dispute ended up being refereed by the CEO.

[Rainer Weikusat]

William Ahern <wil...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> <snip>
>> That someone else already wrote the code is another tangential fact and -
>> strange how it always seems to come back to that
>
> I mention it not because someone else wrote it, because that someone was the
> vendor, and what the vendor provided is being hammered on by every user and
> is a focal point for code inspection. As opposed to ad hoc privsep
> implementations.

All of which together means exactly nothing: The code itself is
relevant for determining the technical properties of some piece of
software, not who wrote or who used or how many people allegedly used
it or to which degree one group of people writing code is admired
while other groups are despised.

>> it is equally true for PAM.
>
> It is equally true for PAM, but not I'm criticing the code quality of PAM,
> but the design decision to use loadable modules, and in particular, not to
> interpose a process boundary between the authenticating agent and the
> authentication mechanism. And by authenticating agent, I mean crap like a
> PHP web application.

But that's not a design descision made by the people who designed PAM:
It's the way UNIX(*) authentication has always worked until some guy,
after a streak of security errors in his code, thought that he really
needed this 'process barrier' to be at least remotely safe from crap
he and his buddies wrote together themselves in earlier times. I'm not
going to question the wisdom of this descision, at least not
seriously (OpenSSH became a lot more 'quiet' in his respect shortly
afterwards), but I question the universality of this experience: Just
because the people who nowadays champion BSD auth have a history of
creating 'security issues' and generally consider it 'hard' to avoid
them doesn't mean this is true for everyone (side note: The so-called
'Dunning-Kruger effect' might make for an interesting read in this
context :->. The more someone is convinced to be the measure of all
things created, the less likely is it that he actually is).

>> Provided that any specific implementation of 'BSD Authentication
>> framework' + 'OS kernel supposed to enforce the isolation' is free of
>> errors with security impact, applications can use it 'securely' but again,
>> the exact same thing is true for PAM.
>
> Wrong. The difference is that PAM is loaded into the process.

If it were free of errors, as I wrote above, this wouldn't matter. It
only matters because you have chosen to assume that 'the process' is a
lot more likely to contain security-relevant errors than 'the code
written by the vendor'. So far, I haven't used a non-trivial piece of
software written by a third party were I didn't have to fix some bugs
already contained in it and I've certainly never written something
non-trivial which didn't have bugs: All software contains coding
errors and is partially built on design errors. The reason for the
latter is usually that one's understanding of a specific problem is
greatly improved by writing code supposed to deal with it: Afterwards,
you'll know what you should have been doing instead.

> I think it's fair to argue that an authenticating agent, like a PHP
> web application or IMAP server, has far more potentially exploitable
> surface area than PAM + kernel (or BSD Auth + kernel) alone.

The kernel is larger than most programs. And 'the exploitable surface
area' of any piece of code is usually rather small: Only the parts
where untrusted data enters the system. Again, the kernel is much
worse in this respect than a typical application because it is
overwhelmingly concerned with providing services to untrusted
applications and consequently, it has a real lof of these entry
points.

[...]

>> Specifically, privilege separation is supposed to mitigate yet unknown
>> coding errors in the applications using the mechanism and from the
>> application standpoint, a facility protecting the application from yet
>> unknown bugs in the authentication code and the kernel would seem just as
>> necessary. "We must do something. This is something. Therefore, we must do
>> it." didn't become any better as rational justification of anything in the
>> meantime. There's also the issue that some programs do nothing but perform
>> privileged operations and consequently, this scheme doesn't even work as
>> 'sysadmin peace of mind' device for them. So what does 'BSD
>> Authentication' offer for such an application, if it actually offers
>> anything, that PAM doesn't offer?
>
> Here's how I understand your argument:
>
> a) Privsep merely protects a broken authenticating program from itself. If
> the authenticating program is broken, then it doesn't matter whether it has
> root privileges because
>
> b) the attacker will just use a kernel exploit, which usually doesn't
> require root privileges.
>
> c) All kernels are exploitable.

It is actually much simpler: I don't think facilities supposed to
mitigate 'unknown errors' are a good idea because 'an unknown problem'
can be anything and be located everywhere, including the code
implementing the facility itself: It may help. Or it may make matters
even worse. Or have no practically relevant effects at all (Software
mechanisms intended to avoid buffer overruns or mitigate the effects
of buffer overruns don't do anything for SQL injection attacks, the
more modern consequence of broken or absent validation of untrusted
input data). And nobody knows which of it will be until 'something has
happened'[*]. Because of this, I'm much more interested in useful
features provided by 'other software' than in 'safeguards which will
hopefully help in case of nebulous future dangers'.

[*] Practical example from a completely different area: I live in a
basement flat with a small garden at the backside, separated from the
yard/ parking space behind it by a wooden door which is about my
height (1.7m). At the other side of this yard is a public footpath
commonly used by people walking home in the early morning hours after
getting drunk and drugged while partying in town. Since I like fresh
air, I usually sleep with the garden-side door of the flat
open. Strange people have entered my place by scaling the outer garden
door in the night at least twice. When this happened for the second
time, my sole winter jacket, a company-provided mobile and my piggy
bank were stolen. This naturally made me put some thought into
measures for avoiding this in future which would nevertheless enable
me to keep the garden door open. Running 2 metres of NATO barbed-wire
across the door and fence (of the same height) at the other side of
the garden would have worked nicely, but - as could be guessed - the
lettings agency people representing the flat owner found this idea
rather queer and I'm not allowed to do that (one of the arguments
brought forth against it was actually that someone who tries to enter
my flat in this way might hurt himself when coming into contact with
the barbed wire and 'might sue someone' because of this :->). Because
of his, I then did the next best thing which came to my mind: Secure
the door with rope in a way I learnt in the Navy for 'fixing' the end
of a rope such that it won't give way under heavy pressure (eg, when
mooring(term?) a ship). This will help little against someone carrying
a moderately large knife or a pair of scissors but nobody will be
able to force the open door by pulling violently, at least not without
breaking the door itself completely. I decided that guarding
against the 'common' case --- random drunk idiot trying to impress an
equally drunk women by performing 'a daring feat' which doesn't really
cost him much effort unprepared --- ought to be sufficient. So far,
this mechansim as survived at least one attempt to get past it, and
even one conducted in a more intelligent way than I had
imagined. 'Some unkown future danger' might render it completely
ineffective but until then, I prefer to sleep instead of worrying
about 'stuff which could also happen'.

[Ian Collins]

I thought the "blanket statement" was your assumption that
authentication schemes all use a password file. Saying most don't is a
simple correction. All of the systems I manage or interact with use
some form of LDAP.

--
Ian Collins

[Rainer Weikusat]

I made no such assumption. 'Using a local password file' just happened
to be one specific example where the 'you have to have euid==0' is
wrong: The process checking the password needs to be able to read the
password hash from the corresponding file. The privileges necessary
for that depend on the filesystem permissions of this file. Eg, on a
Debian system, this means that the process needs to be in group
shadow. Since I had to supply an example myself, you then had the
opportunity to criticise my statement because of this example. Had I
used LDAP as an example, you could - as correctly - have pointed out
that 'most users of the most popular Linux distributions for general
purpose personal computers', Ubuntu, very likely use the installation
without any 'fancy authentication stuff' on their laptops or -
alternatively - that LDAP is only used in halfway 'homegrown'
UNIX(*)-centered networked authentication environments while 'most
enterprise installation' very likely use Kerberos, specifically, the
Kerberos service which comes as part of MS AD. None of this really
matters for the topic at hand.