>> 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.
Ian Collins <ian-n...@hotmail.com> writes:
> On 08/30/12 10:36 AM, Rainer Weikusat wrote:
>> William Ahern<will...@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).
William Ahern <will...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> William Ahern <will...@wilbur.25thandClement.com> writes:
>> > Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> >> William Ahern <will...@wilbur.25thandClement.com> writes:
>> >> > Rainer Weikusat <rweiku...@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 :->.
William Ahern <will...@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.
Rainer Weikusat <rweiku...@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.
Rainer Weikusat <rweiku...@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.
boltar2...@boltar.world wrote:
> 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
RSA pubkey auth. Passwords are magnitudes weaker..
> 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'
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.
William Ahern <will...@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:
> 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 <rweiku...@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?
"James K. Lowden" <jklow...@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.
boltar2...@boltar.world wrote:
> 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.
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:
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.
> Rainer Weikusat <rweiku...@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.
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 ;)
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).
William Ahern <will...@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
>>>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. 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.
William Ahern <will...@wilbur.25thandClement.com> writes:
> Casper H.S. Dik <Casper....@orspamcle.com> wrote:
>> Rainer Weikusat <rweiku...@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.
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).
boltar2...@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.
boltar2...@boltar.world wrote:
> On Fri, 31 Aug 2012 01:43:02 +0100
> Nobody <nob...@nowhere.com> wrote:
> >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).
> 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.
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.
> 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 <will...@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.
William Ahern <will...@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rweiku...@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<ian-n...@hotmail.com> writes:
>> On 08/30/12 10:36 AM, Rainer Weikusat wrote:
>>> William Ahern<will...@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).
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 <ian-n...@hotmail.com> writes:
> On 08/30/12 09:54 PM, Rainer Weikusat wrote:
>> Ian Collins<ian-n...@hotmail.com> writes:
>>> On 08/30/12 10:36 AM, Rainer Weikusat wrote:
>>>> William Ahern<will...@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).
> I thought the "blanket statement" was your assumption that
> authentication schemes all use a password file.
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.
