> >Now, do you view that as saying "Shadow passwords don't provide real
> >protection, therefore let's not use password shadowing at all" and
> I haven't seen anyone suggest that we get rid of shadowed passwords. I
> could be wrong, but it seems obvious that there's nothing to be lost by
> keeping crypted user passwords secret.
Quote:> However, at the same time, it seems to me like there's nothing to be lost
> by assuming shadowed passwords don't work. In many operating system
> releases, they don't. Why not choose and change passwords with the
> assumption that shadowing will fail? It's almost certainly a good
> assumption, if we learn anything from history.
And all of the implmentations of password shadowing I have direct
experience with (the Shadow Password Suite as the author and AIX
for the RS/6000 as a developer) =do= include password strength
> >Or do you take the
> >position that password shadowing relies on overall system security
> >the same as every other aspect of a secure system?
> What a funny thing to say. No, of course shadowed passwords don't rely on
> overall system security "the same as every other aspect of a secure
> system". That's like saying "any enhanced privilege is equivalent to
> root". To hell with least privilege, then! =)
No, pretty much they do. Even in least privilege systems (AIX has
"least privilege" as its underlying implementation, as does VAX/VMS
and many others) there are a small number of "golden key" privileges.
In AIX if you can get SET_PROC_DAC you can read or write any file
on the system. From that point you can get root in one or two
The advantage of least privilege isn't that you can't figure out
ways to amplify one or two stolen privileges into =more= privileges
(generally there is some way to acquire more privileges once you've
figured out how to get one ...), rather that it is harder to get all
of the privileges (or the ones you happen to want) in such a system
than it is on a monolithic privileged system.
"Least privilege" challenges the attacker to figure out how to
use =that= privilege to exploit further flaws to get new privileges
or to use =that= privilege to do something specifically damaging.
It's like saying "Now that you have <X> privilege, what are you
going to do with it?". If the answer is "I don't know.", least
privilege has prevented a further penetration. If the answer is
"I'm going to take my FS_CONFIG privilege and put a filesystem on
a floppy disk and have a set-UID root shell and mount it and then
I'll run it and be root", least privilege has failed. But at least
the attacker had to do some work (and have access to the floppy
Quote:> Shadowed passwords rely on the security of the Unix filesystem (which is
> what you're thinking of), the security of the process control mechanisms,
> and the security of every userland process that at any point has enough
> privilege to pull in crypted passwords. Probably more, but...
So far so good.
Quote:> Small bugs in any of the above that aren't enough to give an attacker root
> access (the ability to cause a once-privileged program to dump a readable
> core, for instance) can be used to compromise the shadowed password system
> without compromising root.
Just as small defects in other parts of the system (say the
ability of a networked user to get sendmail to execute an arbitrary
program) may not directly compromise root.
Quote:> I perceive that you are taking the stance that "anything that compromises
> the shadowed password system compromises root". Is this the case?
Directly compromise root? No. But I believe that small compromises
of system security can usually be parlayed into larger compromises.
I worked a defect in AIX a few years back where you could compromise
the queueing subsystem and within a few steps have a root compromise.
If you look at each compromise in isolation minor defects may not
look significant. But taken as cumulative actions a minor defect
in ftpd which doesn't allow execution as root might give access to
a user's account who =can= su to root and from there root is
Secure systems critically rely on all of the other parts of secure
systems. That was the point behind my mentioning ptrace() and
mknod() in our discussion of chroot().
Julianne Frances Haugh Life is either a daring adventure
Mail: jfh AT bga.com or nothing at all.
-- Helen Keller