Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163393AbbKTUHo (ORCPT ); Fri, 20 Nov 2015 15:07:44 -0500 Received: from imap.thunk.org ([74.207.234.97]:43534 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162428AbbKTUHn (ORCPT ); Fri, 20 Nov 2015 15:07:43 -0500 Date: Fri, 20 Nov 2015 15:07:33 -0500 From: "Theodore Ts'o" To: Octavian Purdila Cc: Dave Chinner , Richard Weinberger , xfs , linux-fsdevel , LKML Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures Message-ID: <20151120200733.GA350@thunk.org> Mail-Followup-To: Theodore Ts'o , Octavian Purdila , Dave Chinner , Richard Weinberger , xfs , linux-fsdevel , LKML References: <1447800381-20167-1-git-send-email-octavian.purdila@intel.com> <20151119232455.GM14311@dastard> <20151120005843.GP14311@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2377 Lines: 45 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/