On Sat, Aug 12, 2000 at 11:26:50AM -0400, Greg A. Woods wrote:
> People do secure exchange of keys for SSH every day you idiot! Just
> because you don't doesn't mean that most of the rest of the world
> doesn't!
To get this right essentially means meeting people in person and
checking their passport. A less trustworthy way is to have *them*
tell you a phone number you can reach them at, and then you call it
hoping it isn't some temporary pager number or payphone booth. Even
then, if the number is in China or Russia I have to wonder what
you've gained.
I'm not going to do that. Call me an idiot again if you like, but I've
already reduced the risks to a tolerable level so why go through this
much trouble?
> > Reducing the damage you face means containment. The first tool that
> > you should think of for containment is filesystem persmissions; and
> > the second tool is chroot/jail.
>
> NO, no, no, NO. The very first tool for containing the potential damage
> of a successful attack is to not put valuable data on the same host as
> the vulnerable application in the first place!
OK that's very true. And if we're going to be pedantic about it, then the
next thing you should think of is a firewall. When it comes to containment
on a single system the first two things you should think of are permissions
and chroot()/jail().
> Chroot() and jail() are very sophisticated tools that are rarely used
> correctly by application programmers, and sometimes not even by
> experience systems programmers.
Good thing I wrote the patch then, rather than leaving it to some poor
CVS admin to get it right. Possibly we should also include a Makefile
with CVS to create a proper directory, along with a warning not to
add any setuid binaries to the area.
> > It does nothing to increase the level of authentication possible, but it
> > does reduce the damage that can be done. For example, since you are more
> > confident that the attacker won't get root, you can be more confident
> > that they won't be able to alter portions of the repository not
> > accessible to any pserver user. Commonly this would be CVSROOT, but
> > it could be more.
>
> Don't be an even worse idiot! You cannot successfully chroot() a CVS
> process into a sub-directory of the CVS repository (i.e. prevent it from
> seeing CVSROOT). That would defeat the entire administrative control of
> CVS!
Please reread what I wrote. I'm not chrooting them any further. Chroot
is what makes me confident they won't break the root user id: there are
no setuid binaries in there, but there are on the rest of the
system. By removing their ability to compromise root I gain confidence
in Unix permissions.
> This is totally irrelevant and partially incorrect. There are many
> other ways to achieve the same degree of protection, and all of them
> involve incredibly grealtly improved overall security.
Yeah I know your philosophy already: the whole rest of the box
ought to be "Orange Book" secure so that nobody can find anything
to attack, even if you give them a full shell on the real root
partition. In practice this means applying every security patch
that comes out before an attacker can use it against me.
No thanks.
It's much easier to secure the limited chroot sandbox than it is to
secure the entire box.
Justin
