All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/2] debugfs: build read-only variant of debugfs
Date: Thu, 17 Nov 2011 16:11:43 -0500	[thread overview]
Message-ID: <20111117211143.GB26341@thunk.org> (raw)
In-Reply-To: <4EC28845.8000200@redhat.com>

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

      reply	other threads:[~2011-11-17 21:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15  5:05 [PATCH 1/2] debugfs: build read-only variant of debugfs Theodore Ts'o
2011-11-15  5:05 ` [PATCH] libquota: log an error message if ext2fs_file_open() fails Theodore Ts'o
2011-11-15  5:05 ` [PATCH 2/2] debugfs: add the freefrag command Theodore Ts'o
2011-11-15 15:41 ` [PATCH 1/2] debugfs: build read-only variant of debugfs Eric Sandeen
2011-11-17 21:11   ` Ted Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111117211143.GB26341@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.