Would you guys PLEASE take this to private email?? Please?
Kate Ebneter
Buildmaster and Rabbit Wrangler
Icras, Inc.
Justin Wells wrote:
>
> 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
