linux-kernel - Re: [PATCH v3 0/7] User namespace mount updates

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

Date:	Tue, 17 Nov 2015 16:01:25 -0600
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-bcache@...r.kernel.org, dm-devel@...hat.com,
	linux-raid@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v3 0/7] User namespace mount updates

On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:
> 
> > >This is absolutely insane, no matter how much LSM snake oil you slatter on
> > >the whole thing.  All of a sudden you are exposing a huge attack surface
> > >in the place where it would hurt most and as the consolation we are offered
> > >basically "Ted is willing to fix holes when they are found".

None of the LSM changes are intended to protect against attacks from
these sorts of attacks at all, so that's irrelevant.

As I said before, I'm also working to find holes up front. That plus a
commitment from the maintainer seems like a good start at least. What
bar would you set for a given filesystem to be considered "safe enough"?

> > For the context of static image attacks, anything that's found
> > _needs_ to be fixed regardless, and unless you can find some way to
> > actually prevent attacks on mounted filesystems that doesn't involve
> > a complete re-write of the filesystem drivers, then there's not much
> > we can do about it.  Yes, unprivileged mounts expose an attack
> > surface, but so does userspace access to the network stack, and so
> > do a lot of other features that are considered essential in a modern
> > general purpose operating system.
> 
> "X is exposes an attack surface.  Y exposes a diferent attack surface.
> Y is considered important.  Therefore X is important enough to implement it"
> 
> Right...

That isn't the argument he made. I would summarize the argument as,
"Saying that X exposes an attack surface isn't by itself enough to
reject X, otherwise we wouldn't expose anything (such as example Y)."

You believe that the attack surface is too large, and that's
understandable. Is it your opinion that this is a fundamental problem
for an in-kernel filesystem driver, i.e. that we can never be confident
enough in an in-kernel filesystem parser to allow untrusted data? If
not, what would it take to establish a level of confidence that you
would be comfortable with?
--
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/