305 lines
12 KiB
HTML
305 lines
12 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.1pre8">
|
|
<TITLE>The Answer Guy 30: Breakin' Out of the chroot() Jail</TITLE>
|
|
</head>
|
|
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ========================================================= -->
|
|
<H4>"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
<P> <hr> <P>
|
|
|
|
<!-- =============================================================== -->
|
|
<H1 align="center"><A NAME="answer">
|
|
<img src="../gx/dennis/qbubble.gif" alt="" border="0" align="middle">
|
|
<a href="./index.html">The Answer Guy</a>
|
|
<img src="../gx/dennis/bbubble.gif" alt="" border="0" align="middle">
|
|
</A></H1> <BR>
|
|
<H4 align="center">By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
Starshine Technical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A> </H4>
|
|
<p><hr><p>
|
|
<H3><img src="../gx/dennis/qbub.gif" alt="(?)" width="50" height="28"
|
|
align="left" border="0">Breakin' Out of the chroot() Jail</H3>
|
|
<H4 ALIGN="center">Or: adding "disabilities" to Linux</H4>
|
|
|
|
<p><strong>From Ron Arts on 25 Jun 1998
|
|
|
|
<!-- begin body -->
|
|
<br><br>
|
|
Hello,
|
|
|
|
<br><br>
|
|
I saw a post by your hand from 26 Apr 98 in
|
|
<A HREF="news:comp.os.linux.development.system"
|
|
>comp.os.linux.development.system</A> where you said a lot of noteworthy
|
|
things on linux security. Also I have been talking to Jos Vos from
|
|
Xopen Systems (who wrote the <TT>ipfwadm</TT> package).
|
|
|
|
<br><br>
|
|
Both you and he noted the possibility to break out of a <TT>chroot</TT> jail
|
|
(once you become root there). It seems that devices are the weak
|
|
factor.
|
|
</strong></p>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>It seems that letting anyone "become root there" is the weak
|
|
factor! If we can reduce the need to "become root" --- by
|
|
providing mechanisms other than "SUID" and "SGID" programs
|
|
for accessing "privileged" operations than we have made
|
|
some progress.
|
|
|
|
<br><br>
|
|
One approach would be the POSIX.1e "capabilities" (which are
|
|
more like VMS style "privileges" than true "capabilities").
|
|
There is a bit of preliminary work being done on this in the
|
|
2.1.x kernels --- but nothing is likely be usable in 2.2
|
|
(so you're looking at Linux 2.4 before there is "stable" support
|
|
for any of that).
|
|
|
|
<br><br>
|
|
Another approach is to limit the damage that '<TT>root</TT>' can do
|
|
using something like the BSD securelevel features. Last I
|
|
heard on the Linux kernel mailing list they had dropped plans
|
|
to put in simple '<TT>securelevel</TT>' support in favor of a
|
|
"more flexible" approach --- which would mesh better with the
|
|
eventual POSIX.1e ("Orange Book") work.
|
|
|
|
<ul>
|
|
<li>(The implementations of 'securelevel' in all of
|
|
the popular BSD variants, free and commercial
|
|
have been vulnerable to a few attacks via the
|
|
<TT>/proc</TT> filesystem and more recently via
|
|
<TT>ptrace()</TT>
|
|
--- so having Linux adopt one of those designs
|
|
might not be a sound idea. We'll see).
|
|
</ul>
|
|
|
|
I'm a little shy on the implementation details and design
|
|
but I think they said it would essentially be a bit field
|
|
of limitations that would be set on a per process basis.
|
|
There would be bits to prevent various syscalls like
|
|
<TT>mknod()</TT>, <TT>chroot()</TT>, <TT>mount()</TT>, etc.
|
|
In the POSIX.1e model
|
|
this would later become the "maximum privileges mask" ---
|
|
and the individual privileges would be set by meta data on
|
|
the executable files (think of that as a list of about 80
|
|
"P" bits rather than just the SUID and SGID bits we have now).
|
|
|
|
<br><br>
|
|
The argument for this is that we could set any set of
|
|
this bits we want on the '<TT>init</TT>' process (PID 1) to accomplish
|
|
the same limitations as we get with BSD's '<TT>securelevel</TT>'.
|
|
|
|
<br><br>
|
|
That's a pretty compelling argument so far as I'm concerned.
|
|
My main hesitation beyond that has to do with code
|
|
complexity. The BSD crowd has been trying to get their
|
|
'<TT>securelevel</TT>' implementations right for years --- and the
|
|
<TT>ptrace()</TT> bug was just found a couple of weeks ago.
|
|
|
|
<br><br>
|
|
It's not a simple problem. NT's "object" model (and I
|
|
use the term "object" very loosely) provides ACL's on
|
|
files, registry keys, and all sorts of other OS elements.
|
|
There is work underway to add ACL support to Linux ---
|
|
over some filesystems at least. However, I'm convinced
|
|
that ACL's are a fundamentally flawed security model ---
|
|
and that opinion is based on some pretty good academic work.
|
|
|
|
<br><br>
|
|
Unfortunately the true capabilities security model entails
|
|
a completely different programming paradigm --- it doesn't
|
|
translate to Unix conventions at all. In my research
|
|
(purely "armchair" or "book larnin'") I spent most of my
|
|
energy trying to unlearn the Unix, Netware, and NT approaches.
|
|
|
|
<br><br>
|
|
You can read more about the capabilities security model at
|
|
Jonathan Shapiro's "EROS" (extremely reliable OS) web site:
|
|
|
|
<blockquote><code> <A HREF="http://www.cis.upenn.edu/~eros/"
|
|
>http://www.cis.upenn.edu/~eros/</A>
|
|
</code></blockquote>
|
|
|
|
(EROS is an ongoing research project which will hopefully
|
|
eventually be available as a production operating system).
|
|
</blockquote>
|
|
|
|
<p><strong><img src="../gx/dennis/qbub.gif" height="28" width="50"
|
|
alt="(?)" border="0"
|
|
>I have been thinking about disabling the <TT>mount()</TT> or
|
|
better the <TT>mknod()</TT> systemcall when executed from <TT>chroot</TT>'ed
|
|
programs (patching the kernel).
|
|
</p></strong>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>I think the "<TT>capabilities</TT>" (or Linux "<TT>securelevel</TT>" or
|
|
"<TT>privmask</TT>") patches will allow you to disable access to these
|
|
sorts of syscalls. I also suspect that these "disabilities"
|
|
(a more apt description really) will be inherited by all
|
|
forked processes. They will certainly need to be immutable
|
|
(by the process) and will have to imply certain disabilities
|
|
with regards to <TT>kmem</TT> and <TT>/proc</TT> access by the
|
|
'<TT>root</TT>' processes
|
|
that are running within these process groups.
|
|
|
|
<br><br>
|
|
You can look at the existing patches (in the recent 2.1.1xx
|
|
kernels) and possibly build on that.
|
|
</blockquote>
|
|
|
|
<p><strong><img src="../gx/dennis/qbub.gif" height="28" width="50"
|
|
alt="(?)" border="0"
|
|
> Do you think that would be worth the effort? We currently run
|
|
<TT>ftpd</TT>, <TT>telnetd</TT>, <TT>sshd</TT> and some more things
|
|
<TT>chroot</TT>'ed in a very minimal linux
|
|
environment. Based on the false assumption that even when you make it
|
|
to becoming root you cannot break out of that.
|
|
</p></strong>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>The assumption that the <TT>chroot()</TT> jail is inescapable by
|
|
rogue root processes is very bad. You've discovered that.
|
|
|
|
<br><br>
|
|
The main advantage for <TT>chroot()</TT> have to do with limiting
|
|
the number of SUID/SGID programs that are accessible in the
|
|
effort to exploit various vulnerabilities that are used to
|
|
<EM>get</EM> root or other unauthorized access. The other advantage
|
|
is that you can limit the amount of snooping that a class
|
|
of users (anonymous and guestgroup ftp, for example) can
|
|
perpetrate on other users on the system.
|
|
|
|
<br><br>
|
|
In other words you can limit the exposure of your "general"
|
|
users from some classes of other users. For a long time
|
|
the most important element of this was to prevent FTP users
|
|
from grabbing your passwd file and running '<TT>crack</TT>' on it.
|
|
With the advent of shadow password systems that has been
|
|
much less of a concern.
|
|
|
|
<br><br>
|
|
These days the most common approach to securing systems
|
|
is to create special, sacrificial hosts for each service
|
|
and class of users. Linux and {Free|Net|Open}-BSD have
|
|
made this an increasingly economical and attractive option
|
|
since we can put any old "junker" 386 or better to work
|
|
in this sort of role (some people are <EM>giving</EM> away 386 and
|
|
486 systems these days). This is easy enough for commercial
|
|
sites --- but more of a problem for ISP's and educational
|
|
sites, which traditionally still have shell access to at
|
|
least some of their machines.
|
|
</blockquote>
|
|
|
|
<p><strong><img src="../gx/dennis/qbub.gif" height="28" width="50"
|
|
alt="(?)" border="0"
|
|
>I think very few programs use <TT>mknod()</TT>, and that probably are
|
|
the programs you wouldn't allow in a <TT>chroot</TT>'ed environment anyway. I
|
|
also think it would be a relatively small patch, I've done some digging and
|
|
- not being a kernel expert - it seemed pretty easy. The only thing
|
|
left to find out is how to detect in the kernel that the current env
|
|
is <TT>chroot</TT>'ed.
|
|
</p></strong>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>The kernel obviously already tracks the 'root' directory
|
|
(device:inode) for every process. I think it's a field
|
|
in the uarea struct (a data structure maintained by the
|
|
kernel for every process).
|
|
</blockquote>
|
|
|
|
<p><strong><img src="../gx/dennis/qbub.gif" height="28" width="50"
|
|
alt="(?)" border="0"
|
|
>Can you offer any thoughts on this, I'd like to know if I am on the
|
|
wrong track (again) here.
|
|
<br><br>
|
|
Thanks in advance,
|
|
<br>Ron Arts
|
|
<br>Netland Internet Services
|
|
</p></strong>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>Look at the existing (2.1.x) sources for references to
|
|
"securelevel" and "capabilities" --- I'm sure they're in there
|
|
somewhere. You can also consider contributing to the
|
|
Linux Security Audit project. See the following URL's for
|
|
more details:
|
|
|
|
<dl><dt>The Linux Weekly News article on it
|
|
(search on the keyword "audit"):
|
|
|
|
<dd><A HREF="http://www.lwn.net/980625/">http://www.lwn.net/980625/</A>
|
|
|
|
<br> <br>
|
|
<dt>Their currently archives/web site:
|
|
<dd><A HREF="http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/"
|
|
>http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/</A>
|
|
</dl>
|
|
|
|
If your organization needs these features and is willing to
|
|
donate some web space and some personnel time and expertise
|
|
to the project --- you'll be doing yourself and all of us
|
|
alot of good.
|
|
</blockquote>
|
|
<!-- end body -->
|
|
<!--================================================================-->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1998, James T. Dennis <BR>
|
|
Published in <I>Linux Gazette</I> Issue 30 July 1998</H5>
|
|
<P> <hr> <P>
|
|
<!--================================================================-->
|
|
<table width="98%"><tr valign="center" align="center">
|
|
<td rowspan="3"><A HREF="./lg_answer30.html"><IMG
|
|
SRC="../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<td><A HREF="tag_SCOkeys.html">SCOkeys</A></td>
|
|
<td><A HREF="tag_chroot.html">chroot</A></td>
|
|
<td><A HREF="tag_dosemu-db.html">dosemu-db</A></td>
|
|
<td><A HREF="tag_NTauth.html">NTauth</A></td>
|
|
<td><A HREF="tag_cdr.html">cdr</A></td>
|
|
<td><A HREF="tag_3270.html">3270</A></td>
|
|
<td><A HREF="linux-questions-only@ssc.comport.html">comport</A></td>
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_lilostop.html">lilostop</A></td>
|
|
<td><A HREF="tag_emulate.html">emulate</A></td>
|
|
<td><A HREF="tag_ppadrivers.html">ppadrivers</A></td>
|
|
<td><A HREF="tag_database.html">database</A></td>
|
|
<td><A HREF="tag_vacation.html">vacation</A></td>
|
|
<td><A HREF="tag_nullmodem.html">nullmodem</A></td>
|
|
<td><A HREF="tag_lockups.html">lockups</A></td>
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_gzipC.html">gzipC</A></td>
|
|
<td><A HREF="tag_newlook.html">newlook</A></td>
|
|
<td><A HREF="tag_c500.html">c500</A></td>
|
|
<td><A HREF="tag_solprint.html">solprint</A></td>
|
|
<td><A HREF="tag_vc1shell.html">vc1shell</A></td>
|
|
<td><A HREF="tag_memleak.html">memleak</A></td>
|
|
<td><A HREF="tag_tvcard.html">tvcard</A></td>
|
|
</tr></table>
|
|
<P> <hr> <P>
|
|
<!--================================================================-->
|
|
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif"
|
|
ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
|
|
ALT="[ Front Page ]"></A>
|
|
<A HREF="lg_bytes30.html"><IMG SRC="../gx/back2.gif"
|
|
ALT="[ Previous Section ]"></A>
|
|
<A HREF="./vrenios.html"><IMG SRC="../gx/fwd.gif"
|
|
ALT="[ Next Section ]"></A>
|
|
<!--startcut ======================================================= -->
|
|
</body>
|
|
</html>
|
|
<!--endcut ========================================================= -->
|