linux security - May 1997 - Re: Re: Re: Buffer Overflows: A Summary

In article <Pine.LNX.3.95.970503190235.5733A-100000@puck.nether.net>,
Myles Uyema  <linux-security@redhat.com> wrote:
> [mod: But from reading the source I think you don''t need a /dev
entry
> to remount the partition without the nodev. Moreover you could MAKE
> the /dev entry and use that if it were necessary. But that is not the
> issue. The issue is that a chrooted environment is not protected against
> a root-user inside the chrooted environment. Try
>     int i, mypid =getpid ();
>     for (i=2;i<32768;i++)
> 	if (i != mypid) kill (i, 9);
> Ok. This doesn''t get him out of the chrooted environment, but you
can
> see that having root in a chrooted environment is almost as powerful
> as non-chrooted.  A chrooted environment should be so minimal that the
> chances of your users becoming root in there are minimal. -- REW]
Actually, it''s worse than that, I think.  Root can escape from a chroot
environment with ptrace() -- attach to some other process outside the
chroot (again, brute-force search over the pid works), overwrite the
process image, and thus run arbitrary code outside the chroot jail.
(It''s probably a somewhat complicated attack.)  In fact, this attack
works for non-root users, too -- if you''ve got any other process
running
outside the jail with the same uid as the process inside the jail, blam.

Another useful technique for escaping from chroot jails is to use the
network.  (For example, forge RPC, rlogin, NFS requests to localhost; etc.)


But!  Get this -- ptrace() and its cousins can be used for good!  One
can use ptrace-like mechanisms to construct up a better mousetrap,er, jail.
The idea is to have a warden which traces the jailed process, receives
an upcall each time the jailed process tries to do a system call, and
validates that syscall against the security policy.

This approach lets you control not just filesystem accesses, but also all
other privileges (e.g. network access); with this, you can stop all the
above jailbreaking attempts.  The result is a much more flexible for
constructing jails; the jail can be customized to the needs of each process.
In this way, you can confine untrusted programs, limit the effects of
successful attacks (such as buffer overflows), compartmentalize, and enforce
least privilege rules.  The warden tool also stays at the user-level, so
you don''t have to worry that mucking around with kernel code introduced
some new bugs.

This is an ongoing research project.  For more information, read the paper at
	http://www.cs.berkeley.edu/~daw/janus/
That page is a bit out of date.  We''ve currently achieved success at
jailing
pre-existing untrusted code like the Netscape web browser (and all its helper
apps, and any Java stuff it may run, etc.).  We''ve also gotten some
preliminary results with using this to jail untrustworthy daemons, such
as sendmail.  More work is ongoing.


What''s the catch?  Well, simply put, the kernel must support a
significantly
fine-grained process tracing mechanism to enable one to write an effective
warden tool.  Solaris 2.x includes sufficient support, but Linux currently
does *not*.  (It''d be nice to change that, if feasible.)

So, if anyone thinks this is a worthwhile approach, let me know.  If I (or
someone else...) writes the relevant Linux kernel code to support fine-grained
process tracing, do folks think Linus would include it in an official release?
If yes, I will work this summer to get this tool working effectively on
Linux.  If not, I''ll probably stick with Solaris, at least for now.