This is a discussion on RE: scp -t . - possible idea for additional parameter - openssh ; > Date: Wed, 10 Oct 2007 10:57:56 -0700> From: william@25thandClement.com > = To: email@example.com > CC: firstname.lastname@example.org > Subject: Re: sc= p -t . - possible idea for additional parameter> > On Wed, Oct 10, 2007 at = 11:30:14AM -0500, ...
> Date: Wed, 10 Oct 2007 10:57:56 -0700> From: william@25thandClement.com> =
To: email@example.com> CC: firstname.lastname@example.org> Subject: Re: sc=
p -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. i=
t's statement like these that i've spent half this past week> rebutting peo=
ple on LWN and LKML.> =
I'll stand by my comment as I intended it. chroot - by and of itself is not=
To blindly, and off the cuff, throw "if you want it secure, chroot it" stat=
ements out there leads to more problems than it solves.
staticly linking (and all the issues caused when library mis-match problems=
that can arise) vs dynamically linking and having to replicate the librari=
es for the chroot'd environment, and everything else that's involved with g=
etting a process/application properly and securely chroot'd is not for the =
For an application to be properly chroot'd it either needs to be designed w=
ith chroot in mind by more experienced developers, or needs to be clearly a=
nd effectively documented so that the not so experienced can do it.
The change that I am suggesting bypasses the inherit issues with chroot thr=
ough simple means.
The fact that scp is designed to just *copy* files either direction is itse=
lf a blessing.
Simple file and directory management that anyone can do can make the remote=
directories secure by not using sym-links, mount point boundaries, etc...
Climb to the top of the charts!=A0 Play Star Shuffle:=A0 the word scramble =
challenge with star power.
openssh-unix-dev mailing list