Chris's Wiki :: blog/unix/ChrootHistory Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/ChrootHistory?atomcommentsDWiki2015-09-25T00:48:43ZRecent comments in Chris's Wiki :: blog/unix/ChrootHistory.By Greg A. Woods on /blog/unix/ChrootHistorytag:CSpace:blog/unix/ChrootHistory:8c8cc5f0baa5f6905d43e497bddebeedc5ccb5a5Greg A. Woods<div class="wikitext"><p>I have a vague recollection of hearing, and/or participating in, a discussion about the chroot() system call and chroot command at BSDCan this spring (2015), possibly with Steve Bourne and Kirk McKusick. As I recall the consensus of the discussion was that existence of the <code>chroot()</code> system call in V7 was intended mostly for testing, particularly of OS distributions. I suspect there are no programs using it in the distribution because such test software was considered throw-away and thus not included in the release distribution.</p>
<p>The <code>chroot()</code> system call does not exist in PWB Unix, and it's not likely in CB Unix either, both having started with v6 and gaining v7 additions in bits and pieces.</p>
<p>However the <code>chroot()</code> system call is in UNIX System III, as is a new <code>chroot</code> command, and <code>nami.c</code> has had a few small changes which make <code>chroot()</code> secure, at least with respect to <code>chdir("/..")</code>. It is also included as a feature in the <code>login</code> command to restrict users on login to a limited subsystem if their shell is specified as an asterisk (by chrooting to their home directory and then execing another <code>login</code> program from the restricted subsystem), so it is clearly intended for security purposes on pre-networked systems.</p>
<p>I suspect though that the security implications of <code>chroot()</code> were considered in V7 (given it was restricted to the superuser), though not so seriously as to consider how one might have broken out from it, and so the missing checks to prevent <code>chdir("/..")</code> from working were merely an oversight -- one that got corrected when the first commercial/external production release, namely System III, was created. Perhaps Norman Wilson might have further insight into some of this history.</p>
<p>The creation of restricted access to timesharing Unix systems goes almost as far back as Unix has been in use outside Research. Wood and Kochan's book <em>"UNIX System Security"</em> from 1985 (with a focus on System V Release 2) has a great deal of material and sample code showing how to set up chroot-ed environments for restricting users to limited working environments on non-networked timesharing systems, but it's far from the first such guide. They also point out that the <code>login</code> command already has built-in support for doing <code>chroot()</code>. They too missed that V7 included a <code>chroot()</code> call.</p>
<p>Ferbrache and Shearer's book <em>"UNIX Installation Security & Integrity"</em> from 1993 suggests testing software in restricted chroot-ed areas to detect trojans even on non-networked systems, though they warn of running anything as root since any call to <code>mknod()</code> could then help break out of the chroot sub-directory.</p>
</div>2015-09-25T00:48:43ZBy Alan on /blog/unix/ChrootHistorytag:CSpace:blog/unix/ChrootHistory:4dc4563549580cecc483076cdadc3441aa641b45Alan<div class="wikitext"><p>There are definitely people who argue that chroot is not a security measure. Including writers of <a href="https://lwn.net/Articles/252794/">LWN articles</a>. The runcompat use-case fits in with that.</p>
<p>Nice history! I think you're right, there's no code to stop "/.." escaping there :).</p>
</div>2015-08-28T12:30:01Z