From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754066AbcEOCdH (ORCPT ); Sat, 14 May 2016 22:33:07 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:33946 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753994AbcEOCdE (ORCPT ); Sat, 14 May 2016 22:33:04 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: James Bottomley Cc: Djalal Harouni , Alexander Viro , Chris Mason , tytso@mit.edu, Serge Hallyn , Josh Triplett , Andy Lutomirski , Seth Forshee , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Dongsu Park , David Herrmann , Miklos Szeredi , Alban Crequy , Dave Chinner In-Reply-To: <1463233614.2355.20.camel@HansenPartnership.com> (James Bottomley's message of "Sat, 14 May 2016 06:46:54 -0700") References: <1462395979.14310.133.camel@HansenPartnership.com> <20160505073636.GA3357@dztty> <1462449388.2419.27.camel@HansenPartnership.com> <20160505214957.GA3071@dztty> <1462486085.2289.23.camel@HansenPartnership.com> <1462923416.14896.10.camel@HansenPartnership.com> <20160511164247.GA9908@dztty.fritz.box> <1462991618.2356.55.camel@HansenPartnership.com> <20160512195552.GB2859@dztty> <1463091852.2380.72.camel@HansenPartnership.com> <20160514095303.GA3476@dztty> <1463233614.2355.20.camel@HansenPartnership.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Sat, 14 May 2016 21:21:55 -0500 Message-ID: <87twi0giws.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+OpBFwOuIUynNAe9//Tvko40DkQiAxXFU= X-SA-Exim-Connect-IP: 97.119.107.188 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 TR_Symld_Words too many words that have symbols inside * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;James Bottomley X-Spam-Relay-Country: X-Spam-Timing: total 1010 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 7 (0.7%), b_tie_ro: 5 (0.5%), parse: 1.56 (0.2%), extract_message_metadata: 17 (1.7%), get_uri_detail_list: 4.2 (0.4%), tests_pri_-1000: 6 (0.6%), tests_pri_-950: 1.34 (0.1%), tests_pri_-900: 1.10 (0.1%), tests_pri_-400: 33 (3.3%), check_bayes: 32 (3.1%), b_tokenize: 10 (1.0%), b_tok_get_all: 11 (1.1%), b_comp_prob: 3.7 (0.4%), b_tok_touch_all: 3.8 (0.4%), b_finish: 1.00 (0.1%), tests_pri_0: 933 (92.3%), check_dkim_signature: 0.87 (0.1%), check_dkim_adsp: 3.7 (0.4%), tests_pri_500: 6 (0.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Bottomley writes: > On Sat, 2016-05-14 at 10:53 +0100, Djalal Harouni wrote: Just a couple of quick comments from a very high level design point. - I think a shiftfs is valuable in the same way that overlayfs is valuable. Esepcially in the Docker case where a lot of containers want a shared base image (for efficiency), but it is desirable to run those containers in different user namespaces for safety. - It is also the plan to make it possible to mount a filesystem where the uids and gids of that filesystem on disk do not have a one to one mapping to kernel uids and gids. 99% of the work has already be done, for all filesystem except XFS. That said there are some significant issues to work through, before something like that can be enabled. * Handling of uids/gids on disk that don't map into a kuid/kgid. * Safety from poisoned filesystem images. I have slowly been working with Seth Forshee on these issues as the last thing I want is to introduce more security bugs right now. Seth being a braver man than I am has already merged his changes into the Ubuntu kernel. Right now we are targeting fuse, because fuse is already designed to handle poisoned filesystem images. So to safely enable this kind of mapping for fuse is not a giant step. The big thing from my point of view is to get the VFS interfaces correct so that the VFS handles all of the weird cases that come up with uids and gids that don't map, and any other weird cases. Keeping the weird bits out of the filesystems. James, Djalal I regert I have not been able to read through either of your patches cloesely yet. From a high level view I believe there are use cases for both approaches, and the use cases do not necessarily overlap. Djalal I think you are seeing the upsides and not the practical dangers of poisoned filesystem images. James I think you are missing the fact that all filesystems already have the make_kuid and make_kgid calls right where the data comes off disk, and the from_kuid and from_kgid calls right where the on-disk data is being created just before it goes on disk. Which means that the actual impact on filesystems of the translation is trivial. Where the actual impact of filesystems is much higher is the infrastructure needed to ensure poisoned filesystem images do not cause a kernel compromise. That extends to the filesystem testing and code review process beyond and is more than just a kernel problem. Hardening that attack surface of the disk side of filesystems is difficult especially when not impacting filesystem performance. So I don't think it makes sense to frame this as an either/or situation. I think there is a need for both solutions. Djalal if you could work with Seth I think that would be very useful. I know I am dragging my heels there but I really hope I can dig in and get everything reviewed and merged soonish. James if you could see shiftfs with a different set of merits than what to Djalal is doing I think that would be useful. As it would allow everyone to concentrate on getting the bugs out of their solutions. That said I am not certain shiftfs makes sense without Seth's patches to handle the weird cases at the VFS level. What do you do with uids and gids that don't map? You can reinvent how to handle the strange cases in shfitfs or we can work on solving this problem at the VFS level so people don't have to go through the error prone work of reinventing solutions. The big ugly nasty in all of this is that we are fundamentally dealing with uids and gids which are security identifiers. Practically any bug is exploitable and CVE worthy. So it make sense to tread very carefully. Even with care it can takes months if not years to get the number of bugs down to a level where you are not the favorite target of people looking for exploitable kernel bugs. Eric