[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120828144110.GA23035@thunk.org>
Date: Tue, 28 Aug 2012 10:41:10 -0400
From: Theodore Ts'o <tytso@....edu>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ben Hutchings <ben@...adent.org.uk>,
Rob Landley <rob@...dley.net>,
Al Viro <viro@...iv.linux.org.uk>,
Ludwig Nussel <ludwig.nussel@...e.de>,
Alessandro Rubini <rubini@...dd.com>, linux-doc@...r.kernel.org
Subject: Hardening debugfs (Was Re: [PATCH] debugfs: more tightly restrict
default mount mode)
On Mon, Aug 27, 2012 at 01:32:15PM -0700, Kees Cook wrote:
> Since the debugfs is mostly only used by root, make the default mount
> mode 0700. Most system owners do not need a more permissive value,
> but they can choose to weaken the restrictions via their fstab.
>
> Signed-off-by: Kees Cook <keescook@...omium.org>
I agree with this patch, but it would also be good if we could try to
harden debugfs in general. Some ideas that might be worth discussing,
for example?
1) Adding a per-module flag, so things in debugfs only show up if they
are explicitly requested (you know, for debugging purposes). If most
people are using debugfs for access to ftrace and powertap (my use
case), there's no point making directories for other device drivers
and file systems visible.
2) Can we find a pattern of common security #fail's with debugfs
files, and try to sweep through and fix them?
There may be other ideas, and again, I'm not saying that this means we
shouldn't lock down the permissions on debugfs. But a both/and
approach might be useful here....
- Ted
--
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/
Powered by blists - more mailing lists