Re: [RFC PATCH] xfs: support for non-mmu architectures

From: "Theodore Ts'o" <tytso@mit.edu>
To: Octavian Purdila <octavian.purdila@intel.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	xfs <xfs@oss.sgi.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures
Date: Fri, 20 Nov 2015 15:07:33 -0500	[thread overview]
Message-ID: <20151120200733.GA350@thunk.org> (raw)
In-Reply-To: <CAE1zotLw-vCz2qF4JmXEYFF_yPbkhQ2HEEYxMwvdRbhKRCaxTw@mail.gmail.com>

On Fri, Nov 20, 2015 at 04:26:28PM +0200, Octavian Purdila wrote:
> It is already possible to mount arbitrary filesystem images in
> userspace using VMs . LKL doesn't change that, it just reduces the
> amount of dependencies you need to do so.

It is true that you can mount arbitrary file systems in userspace
using VM's.  But those the kvm binary is typically not run with root
privileges in the host OS --- at least, not if the system
administrator is smart.  So a root compromise does not cause a
catastrophic security vulnerability, and if the guest OS crashes ---
again, not a real problem.

In the caase where people are trying to claim that containers are just
as secure as VM's, and plan to give container "guest" system
administrators root-like powers, the question which immediately comes
to mind is whether the LKML/fuse daemon is running inside or outside
the container.  If it is outside the container, the a potential
security compromise of the binary running binary will be catastrophic
to the overall security of the host system and all of its containers.
If it is inside the container, you will be partially breaking the
illusion that the container works just like a VM (since a user runinng
"ps" will see all of these mysterious userspace processes that could
be killed, etc.), but it significantly reduces the security problems
if a maliciously crafted (or maliciously modulated) block device is
mounted.

> Could you expand of what burden does this use-case put on fs
> developers? I am sure that, if needed, we can put restrictions in LKL
> to avoid that.

The bottom line is who is going to get all of the support calls and
nasty e-mails explaining how our "crappy" code has caused some silly
container VM system administrator's customers $$$ worth of losses.  As
long as we can make sure that it's been underlined that the code is
being used well outside of its intended scope, and if it breaks, the
user gets to keep both pieces, and all complaints, threatened
lawsuits, etc. should go to the LKL maintainers or the purveyors of
said container-based products, I suppose that should be OK.  :-)

						- Ted