linux-ext4 - Re: [PATCH 1/2] debugfs: build read-only variant of debugfs

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20111117211143.GB26341@thunk.org>
Date:	Thu, 17 Nov 2011 16:11:43 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 1/2] debugfs: build read-only variant of debugfs

On Tue, Nov 15, 2011 at 09:41:57AM -0600, Eric Sandeen wrote:
> On 11/14/11 11:05 PM, Theodore Ts'o wrote:
> > Create a version of debugfs which only supports read-only examination
> > of the file system metadata (but not the data blocks).  The idea is
> > that this version of debugfs might be suitable to be setuid root, and
> > executable only by members of a particular group, or setgid disk, and
> > globally executable, depending on the security/privacy policies in
> > force at a particular site.
> 
> Just curious - what problem does this solve?
> 
> (Could the same policies simply make direct access to block devices
> read-only for those users, and thus have an fs-independent solution
> to whatever problem is at hand?)

It's not enough to make access to the block devices be read-only;
what's most important in this patch is removing the ability to show
data blocks (i.e., removing the debugfs "cat" and "dump" commands).
After all, a company with very strict user data privacy policies might
require a developer to jump through hoops before getting access which
allowed him or her to bypass file system access controls, whether it
is logging in as root or installing some setuid/setgid binary which
had the effect of bypassing mandatory or discretionary access controls
--- which debugfs's "dump" and "cat" commands effectively do.

There's another reason for removing all of the commands that might be
used to modify file system metadata, as well as forcing the block
device to be opened read-only.  It makes it easier for a
security/privacy committee who might want to audit the code to make
sure no one can use the restricted version of debugfs to flip a setuid
bit, or change a file's permissions, or some other entertaining file
system modification.

I could also imagine this sort of thing could also being useful for
advanced support personnel who need to go on site (say, at a financial
institution in NYC) and who needs to debug a customer's file system or
investigate a performance problem.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html