RE: securety related question...
Bill maltby - LFS Related <[email protected]>
| Newsgroups | gmane.linux.lfs.security |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 7 Oct 2002, Soft Skulled Person wrote: > > -----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, Dump it. I've always distrusted/disliked arrogant behaviour by those who "... are standards unto themselves...". DJB falls into this category, even going so far as to (apparently) believe his stuff is so good that no quality documentation is needed. Of course, your problem will still be there. > 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. ROTFLMAO! :-)) Ahhh, Bob! It will now take me another 30 minutes before I can feel sleepy enough to do what I should have done two hours ago - turn in for the night! Just to make sure there is clear understanding - you could see my reply was saying that the suggestions were *not* necessarily "soft-skulled" and that one who would arbitrarily deem it so was possibly the "soft-skulled" one? Item 2: "soft-skulled" = malleable = amenable to change in form or function. There may be the seeds of creativity there. And survivability. I point out that infants less than about a year of age are less susceptible to concussion injuries to the brain because their skull has not yet joined all pieces and hardened. Unfortunaetly, many older individuals have excessive hardening of the skull, resulting in less creativity and higher risk of (self-inflicted) injury. > BK Stay the course. -- Bill Maltby [email protected] -- Unsubscribe: send email to [email protected] and put 'unsubscribe lfs-security' in the subject header of the message