Re: chroot useful?

[Anton J Aylward <anton () toronto com>]

At 07:12 PM 16/11/97 +1100, Darren Reed wrote:
## Reply Start ##

> > > could be converted to do that or make it possible.
> >
> > suppose I don't have a /dev/kmem - see LINUX
>
> Hmmm ?  This doesn't exactly mean a lot.


LINUX doesn't have a /dev/kmem, it uses a /proc vie of things.


> > suppose I don't have a /dev in my chroot()'d environment
>
> You create it.  mkdir(2)
>
> > suppose I have a /dev/kmem in my chroot'd environment which is 
> >         actually /dev/null
>
> unlink("/dev/null");
> mknod("/dev/kmem", 0667, 0xkmem_device);

Right, how?
I'm not supplying you with a compiler & library, therefore you 
have to have some mechanism of uploading a previously compiled 
binary into the chroot'd area.  You're blithely bypassing this
step.

Most security is an onion-skin approach.  Your argument seems 
to be based on an absolutist approach.  "Because chroot CAN be 
subverted given this set of conditions you should NOT use it."
I disagree.  If chroot()ing smap or ftpd can reduce the vulnerability
by 80%, that's 80% less I have to worry about.   I don't expect 
using chroot() to be my ONLY defense.  

I normally use chroot as an area to run smap (or equivalent).
No shell.  No user accounts on the machine.  (Not that there's
anything they can much do on the 'firewall' (HOHOHOHO) even
if they break into it.  For example, by the time smap is 
actually reading from its input its no longer running as
root, so even a buffer overrun forcing the mknod() code
down its throat - assuming I haven't made other kernel fixes
courtesy of Solar woszzisname - won't do anything.  

Mount options on many file systems allow for "no setuid".
Perhaps we need to add a "mknod restricted to regular files only"
mount option as well.  How about contributing that code to the
list to go along with Marcus's changes?

I repeat, security is an onionskin approach.
Anyone with experience in this business knows that there is no
SINGLE cure, (Other than Marcus's Perfect Firewall).  I drill
this into my clients and address it at all my presentations.

And I still know full well that even if I have a "firewall"
(HOHOHOHO) which is 99.9999998% guaranteed to keep the
internet hackers out (or even Marcus's PF) I'm still only
curing about 20% of the problem.

But one final thing: lets work on coming up with improvements 
to make the defense more effective.  Lets not throw out layers
of the onionskin just because, by themselves, they could be
subverted.

/anton

## Reply End ##
--------------------------------------------------------------------------
Anton J Aylward                  | "Quality refers to the extent to which 
The Strahn & Strachan Group Inc  | processes, products, services, and 
Information Security Consultants | relationships are free from defects, 
Voice: (416) 421-8182            | constraints and items which do not add
  Fax: (416) 421-8183            | value." - Dr. Mildred G Pryor, 1995