linux-kernel - Chroot bug take 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <46FE6D8F.70808@davidnewall.com>
Date:	Sun, 30 Sep 2007 00:51:51 +0930
From:	David Newall <david@...idnewall.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Chroot bug take 3

/.

I hope I haven't crossed the line between determined and annoying.  I 
thought we were done, but now I find meat still on this bone.

Posit a normal process having some filesystem root, and a current 
working directory (pwd) lying within that root subtree.  When chroot is 
performed, pwd is left unchanged.  This means it can (and often will) 
lie outside of the new root.

How much of the filesystem lying outside of root should a process be 
allowed to access?  Currently it is the complete filesystem.

It is perfectly reasonable for a process to execute chroot multiple 
times, each time pruning off access to further parts of the filesystem.  
What is *not reasonable* is chroot unavoidably returning access which 
previously had been dropped.  Similarly, performing fchdir on a 
directory opened prior to chroot should not grant access to more of the 
filesystem than was accessible when the directory was opened.

Although chroot can result in pwd lying outside of the new root, is must 
still lie within some root.  A new quantity, openfdroot, will be 
recorded by chroot, to be used as the limit when walking dotdot outside 
of the current root.

The initial value for openfdroot is the complete filesystem.  After 
completing each chroot, as well as chdir, fchdir and close, openfdroot 
will be set to root iff all open directories and pwd lie within that 
root; otherwise it remains unchanged.

In an ideal world a separate openfdroot would be recorded for each open 
directory, and another for pwd, however this is extreme.  A single value 
permits chroot to perform its fundamental promise, namely to prune the root

The following might replace the last two paragraphs in chroot(2)'s 
description:

    This call does not change the current working directory.  After the
    call, '.' can be outside of path, thus files, accessible to the
    process before the call, remain accessible (via relative pathnames)
    afterwards.  This access is intrinsicly dropped by changing
    directory to within the new root.

    This call does not close open file descriptors, and such descriptors
    may allow access to files outside the chroot tree.  A successful
    open(2) on a directory outside of path yields a descriptor that can
    subsequently be passed to fchdir(2) to escape the new root.  This
    will only provide access to as much of the filesystem as was
    accessable when the directory was opened.  Closing all such files
    (and changing directory to within path) drops this access.

Would there be any point in working up a patch?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/