Re: securety related question...

On Sun, 6 Oct 2002 [email protected] wrote:

> On Sun, 6 Oct 2002, Bill maltby - LFS Related wrote:
> 
> > *chuckle*. I almost agree with this. If you remove the word *utterly*. The
> > intended purpose is to allow a "redirection" of the root of the tree for a
> > particular process or application. It has many uses other than denying
> > access. For instance, the -r parameter to lilo allows running with a set
> > of files and images different from what it would normally "see". The point
> > is not to deny access, but to ease "use of". It is only a nice side-effect
> > that it can be used to deny access, but in programming activities has
> > *many* other uses.
> 
> Okay, then we've got a very simple place to draw the line in the sand on
> this one.  People chrooting to facilitate something can use mount all they
> like.  People chrooting to _secure_ something had better not do such a
> soft-skulled thing.

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.

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?

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.

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.

-- 
Bill Maltby
[email protected]


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