From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758368AbdEVTKh (ORCPT ); Mon, 22 May 2017 15:10:37 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:46924 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979AbdEVTKf (ORCPT ); Mon, 22 May 2017 15:10:35 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: David Howells Cc: 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 References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> Date: Mon, 22 May 2017 14:04:00 -0500 In-Reply-To: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> (David Howells's message of "Mon, 22 May 2017 17:22:26 +0100") Message-ID: <87lgpoww67.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=1dCsiu-0005d4-TL;;;mid=<87lgpoww67.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/doYKnbaCWlXveQQ2ibSyaXUud7+W6jhQ= 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 352 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.0 (1.1%), b_tie_ro: 2.7 (0.8%), parse: 1.43 (0.4%), extract_message_metadata: 6 (1.7%), get_uri_detail_list: 3.1 (0.9%), tests_pri_-1000: 4.8 (1.4%), tests_pri_-950: 1.81 (0.5%), tests_pri_-900: 1.46 (0.4%), tests_pri_-400: 36 (10.2%), check_bayes: 30 (8.7%), b_tokenize: 12 (3.5%), b_tok_get_all: 8 (2.4%), b_comp_prob: 3.5 (1.0%), b_tok_touch_all: 2.7 (0.8%), b_finish: 1.03 (0.3%), tests_pri_0: 278 (78.8%), check_dkim_signature: 0.81 (0.2%), check_dkim_adsp: 4.1 (1.2%), tests_pri_500: 6 (1.8%), 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: > Here are a set of patches to define a container object for the kernel and > to provide some methods to create and manipulate them. > > The reason I think this is necessary is that the kernel has no idea how to > direct upcalls to what userspace considers to be a container - current > Linux practice appears to make a "container" just an arbitrarily chosen > junction of namespaces, control groups and files, which may be changed > individually within the "container". > I think this might possibly be a useful abstraction for solving the keyring upcalls if it was something created implicitly. fork_into_container for use by keyring upcalls is currently a security vulnerability as it allows escaping all of a containers cgroups. But you have that on your list of things to fix. However you don't have seccomp and a few other things. Before we had kthreadd in the kernel upcalls always had issues because the code to reset all of the userspace bits and make the forked task suitable for running upcalls was always missing some detail. It is a very bug-prone kind of idiom that you are talking about. It is doubly bug-prone because the wrongness is visible to userspace and as such might get become a frozen KABI guarantee. Let me suggest a concrete alternative: - At the time of mount observer the mounters user namespace. - Find the mounters pid namespace. - If the mounters pid namespace is owned by the mounters user namespace walk up the pid namespace tree to the first pid namespace owned by that user namespace. - If the mounters pid namespace is not owned by the mounters user namespace fail the mount it is going to need to make upcalls as will not be possible. - Hold a reference to the pid namespace that was found. Then when an upcall needs to be made fork a child of the init process of the specified pid namespace. Or fail if the init process of the pid namespace has died. That should always work and it does not require keeping expensive state where we did not have it previously. Further because the semantics are fork a child of a particular pid namespace's init as features get added to the kernel this code remains well defined. For ordinary request-key upcalls we should be able to use the same rules and just not save/restore things in the kernel. A huge advantage of my alternative (other than not being a bit-rot magnet) is that it should drop into existing container infrastructure without problems. The rule for container implementors is simple to use security key infrastructure you need to have created a pid namespace in your user namespace. Eric