From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030992AbdEWPaj (ORCPT ); Tue, 23 May 2017 11:30:39 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:35596 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760110AbdEWPac (ORCPT ); Tue, 23 May 2017 11:30:32 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: David Howells Cc: James Bottomley , trondmy@primarydata.com, mszeredi@redhat.com, linux-nfs@vger.kernel.org, jlayton@redhat.com, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, Linux Containers References: <1495472039.2757.19.camel@HansenPartnership.com> <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> <32556.1495547529@warthog.procyon.org.uk> Date: Tue, 23 May 2017 10:23:46 -0500 In-Reply-To: <32556.1495547529@warthog.procyon.org.uk> (David Howells's message of "Tue, 23 May 2017 14:52:09 +0100") Message-ID: <87inkrlhq5.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dDBlX-0001G4-1W;;;mid=<87inkrlhq5.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX186ofjyRfoElzHAWdpN9Yho/RBecV6k0GU= X-SA-Exim-Connect-IP: 97.121.81.159 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 XMNoVowels Alpha-numberic number with no vowels * 1.5 TR_Symld_Words too many words that have symbols inside * 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 * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;David Howells X-Spam-Relay-Country: X-Spam-Timing: total 139 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 2.8 (2.0%), b_tie_ro: 1.93 (1.4%), parse: 0.62 (0.4%), extract_message_metadata: 2.00 (1.4%), get_uri_detail_list: 0.67 (0.5%), tests_pri_-1000: 3.0 (2.2%), tests_pri_-950: 0.94 (0.7%), tests_pri_-900: 0.75 (0.5%), tests_pri_-400: 14 (10.3%), check_bayes: 14 (9.7%), b_tokenize: 4.1 (2.9%), b_tok_get_all: 4.8 (3.4%), b_comp_prob: 1.39 (1.0%), b_tok_touch_all: 1.91 (1.4%), b_finish: 0.46 (0.3%), tests_pri_0: 106 (75.9%), check_dkim_signature: 0.39 (0.3%), check_dkim_adsp: 6 (4.1%), tests_pri_500: 3.2 (2.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Howells writes: > Another thing that could be useful is a list of what device files a container > may access, so that we can allow limited mounting by the container root user > within the container. That is totally not why that isn't allowed, and won't be allowed any time soon. The issue is that the filesystem implementations in the kernel are not prepared to handle hostile filesystem data structures so that that is the definition of a kernel exploit. The attack surface of the kernel gets quite a bit larger in that case. Perhaps if all of the filesystems data structures had a hmac on them we could allow something like this. Once we can make it safe it is easy to add an appropriate interface. We most defintiely don't need a ``container'' data structure in the kernel to do that. A completely unprivileged fuse is much more likely to work for this use case. And we do already have have the device cgroup which sort of does this. Eric