Re: securety related question...

On Sun, 6 Oct 2002, Bill maltby - LFS Related wrote:

> It seems to me that the proper use of any tool to accomplish the desired
> objective, within the constraints imposed by the environment (cost, space,
> time, knowledge...) is not "soft-skulled", but rather the denigration of
> that proper use would be so.

Well, unfortunately you're talking about something entirely separate from
using mount --bind to defeat one's own chroot jail.  I suppose if the
original intention is to get a cricket off your shoe, then pointing a
shotgun at your toes _might_ be a good first step, however intelligent
people would probably use the butt of the gun to squash it instead of
blowing their toes off.

> If after proper investigation and analysis, one decides that use of mount
> --bind, in conjunction with a chroot environment, gives a level of
> security appropriate to the task, what is wrong with that? It may not be a
> steel cask secreted in a salt mine thousands of feet below ground and
> overlayed by hundresds of feet of granite, but who needs that for his
> piggy bank?

I think you're completely distorting things here now.  You can go and do
that level of research if you like if you have a specific problem you know
about that you're not mentioning to the rest of the list, but under
normal, generic, circumstances, it's _not_ the right answer and you'd be a
fool to recommend it as a _general_ solution to the problem of files
missing from a chroot jail when /bin/cp can solve the problem _without_
exposing the system to extra risk.

Smart people do _not_ spend tons of time trying to "research" new ways of
doing _lazy_ things like remounting whole filesystems inside a chroot jail
like this when there is a _simple_, _tested_, and _reliable_ method for
accomplishing the task already in the books.

> Security is always a cost-benefit trade off. After the proper assessment,
> reduction, assignment, avoidance and acceptance, the implementation of a
> plan *appropriate* to the value of what is being protected and the cost
> and perceived risk is the *proper* course to follow. Anything else is
> willful negligence. And that includes *overkill* for the task.

Blah, blah, blah.  Don't waste your time trying to make yourself look as
if you know what you're talking about by being the first person to try to
lecture the other about basic security procedures.  The generic talk above
is pretty useless considering the discussion is about a very specific
issue.

> Of course, experience with using the decided-upon strategy may reveal that
> invalid assumptions were used or there were unexpectedly greater
> risks. Then one hopes that the learning experience was not too costly.

Yes, I can only hope that the people who listen to your "advice" don't get
too terribly burned when they find out the hard way _why_ files inside a
chroot jail should have absolutely no connection with files (or
partitions) used _outside_ the chroot jail.

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message