[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110718134503.GC8127@mail.hallyn.com>
Date: Mon, 18 Jul 2011 19:01:10 +0000
From: "Serge E. Hallyn" <serge@...lyn.com>
To: David Safford <safford@...son.ibm.com>
Cc: Kyle Moffett <kyle@...fetthome.net>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
James Morris <jmorris@...ei.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>,
Dmitry Kasatkin <dmitry.s.kasatkin@...il.com>
Subject: Re: [PATCH v7 00/16] EVM
(sorry, just realized postfix has been messing up my email, hope this
comes through ok)
Quoting David Safford (safford@...son.ibm.com):
> On Wed, 2011-06-29 at 21:57 -0400, Kyle Moffett wrote:
> > There have been numerous cases in the past where a corrupt or invalid
> > filesystem causes kernel panics or even exploitable overflows or memory
> > corruption; see the history of the "fsfuzzer" tool for more information.
>
> Seems to me code bugs in the kernel should be fixed, given the universal
> practice of automounting of removable media, and loopback mounting
> images, regardless of EVM.
Hi David,
yeah, this would also be nice for making people feel cozier about
supporting unprivileged fs mounts in general. I wonder if a real
project around the idea of strengthening the robustness of the fs
code, starting with the superblock parsing for a few of the most
comment filesystems, could take off. A combination of
. code auditing and test (i.e. fsfuzzer)
. moving parts of the code to unprivileged userspace
. marking audited filesystems as unprivileged-mountable, in the
way Miklos' patchset a few years ago did
. so that those who want to can refuse auto-mount of any not
audited filesystems.
-serge
----- End forwarded message -----
--
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