RE: securety related question...

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Bill
> maltby - LFS Related
> Sent: Sunday, October 06, 2002 11:28 PM
> To: [email protected]
> Subject: Re: securety related question...
>
>
> On Sun, 6 Oct 2002 [email protected] wrote:
>
<snip>
>
> > 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.
>

Perhaps I should chime in, as the soft-skulled person who first suggested
this idea.  While I am frequently soft-skulled about many topics, including
Linux (which is the reason I ask questions on groups like this), and while
agreeing with the analysis above concerning the trade-off between cost and
benefit, I would like to add that, even when one is looking for the salt
mine thousands of feet below ground et.al. solution, it is not entirely
clear how to achieve it.  For example, one of the apps I am running is
qmail.  Someone has posted some helpful suggestions on how to chroot
several of the qmail programs in a traditional fashion, although, to my
eye, it looks like this requires modification of the source code, and a
soft-skulled person probably shouldn't do that.  Furthermore, at least
one of the programs doesn't seem to be suitable for traditional chrooting
(since it accesses user directories), and the proposed non-soft-skulled
solution of copying the files needed by the app into the chroot jail
wouldn't work, since the user directory files need to be accessed and
modified by the users.  An alternative, of course, is not to chroot this
app at all, but it is hard for me to see how this is less soft-skulled than
the original idea (it seems, in the worst case, that the chroot with --bind
would be completely ineffective, giving the app access to the entire file
system, which is what happens if you don't chroot, making the don't-chroot-
at-all solution equally soft-skulled).  To sum up, I am perfectly willing
to consider any non-soft-skulled solution for how to deal with something
like qmail, and, while one person has provided a helpful solution that gets
me part way there, no one has given me a solution that is completely non-
soft-skulled.  And it looks like I am too soft-skulled to think of a
solution on my own.  So, in the absence of further guidance, I am going to
try the soft-skulled solution, at least on a temporary basis, since none
of the alternatives seem less soft-skulled.

BK

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