On 10/10/07 18:29, Larry Becke wrote:
>> Date: Wed, 10 Oct 2007 10:57:56 -0700> From: william@25thandClement.com> To: guyverdh@hotmail.com> CC: openssh-unix-dev@mindrot.org> Subject: Re: scp -t . - possible idea for additional parameter> > On Wed, Oct 10, 2007 at 11:30:14AM -0500, Larry Becke wrote:> > chroot'ing should not be used as a security method, that's been clearly> > stated time and again.> > oh boy. it's statement like these that i've spent half this past week> rebutting people on LWN and LKML.>

> I'll stand by my comment as I intended it. chroot - by and of itself is not security function.

What does that even mean?

> To blindly, and off the cuff, throw "if you want it secure, chroot it" statements out there leads to more problems than it solves.

No one threw out any such statements. What I said was "If you want to
confine users effectively, chroot them."

> staticly linking (and all the issues caused when library mis-match problems that can arise) vs dynamically linking and having to replicate the libraries for the chroot'd environment

It's really not that big of a deal. You don't need to relink. What
library mismatch problems are you referring to?

> and everything else that's involved with getting a process/application

properly and securely chroot'd is not for the beginner.

Neither is trying to set up a protected filesystem hierarchy using a
modified scp as a shell.

> For an application to be properly chroot'd it either needs to be designed with chroot in mind by more experienced developers, or needs to be clearly and effectively documented so that the not so experienced can do it.

Most reasonably advanced admins can chroot pretty much any service
without special documentation. ldd and strace (or equivalent) are your
friends. If you design your chroot properly it's trivial to maintain.

Jefferson Ogata
NOAA Computer Incident Response Team (N-CIRT)
"Never try to retrieve anything from a bear."--National Park Service
openssh-unix-dev mailing list