From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752610AbdJLSA0 (ORCPT ); Thu, 12 Oct 2017 14:00:26 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:41387 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbdJLSAX (ORCPT ); Thu, 12 Oct 2017 14:00:23 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Richard Guy Briggs Cc: cgroups@vger.kernel.org, Linux Containers , Linux API , Linux Audit , Linux FS Devel , Linux Kernel , Linux Network Development , Simo Sorce , "Carlos O'Donell" , Aristeu Rozanski , David Howells , Eric Paris , jlayton@redhat.com, Andy Lutomirski , mszeredi@redhat.com, Paul Moore , "Serge E. Hallyn" , Steve Grubb , trondmy@primarydata.com, Al Viro References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> Date: Thu, 12 Oct 2017 12:59:57 -0500 In-Reply-To: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> (Richard Guy Briggs's message of "Thu, 12 Oct 2017 10:14:00 -0400") Message-ID: <8760bkxn4y.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=1e2hmM-0001bG-1B;;;mid=<8760bkxn4y.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.233.18;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18p9NJYK18UXtr0W+yYL3EnIGDihDU8sa4= X-SA-Exim-Connect-IP: 67.3.233.18 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 TVD_RCVD_IP Message was received from an IP address * 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: *;Richard Guy Briggs X-Spam-Relay-Country: X-Spam-Timing: total 446 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.4 (0.5%), b_tie_ro: 1.72 (0.4%), parse: 0.72 (0.2%), extract_message_metadata: 2.6 (0.6%), get_uri_detail_list: 1.14 (0.3%), tests_pri_-1000: 4.5 (1.0%), tests_pri_-950: 1.13 (0.3%), tests_pri_-900: 0.99 (0.2%), tests_pri_-400: 22 (4.8%), check_bayes: 21 (4.6%), b_tokenize: 7 (1.6%), b_tok_get_all: 7 (1.6%), b_comp_prob: 2.1 (0.5%), b_tok_touch_all: 2.4 (0.5%), b_finish: 0.52 (0.1%), tests_pri_0: 401 (89.9%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 3.7 (0.8%), tests_pri_500: 3.5 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: RFC(v2): Audit Kernel Container IDs 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 Richard Guy Briggs writes: > A namespace cannot directly migrate from one container to another but > could be assigned to a newly spawned container. A namespace can be > moved from one container to another indirectly by having that namespace > used in a second process in another container and then ending all the > processes in the first container. Ugh no. The semantics here are way too mushy. We need a clean crisp unambiguous definition or it will be impossible to get this correct and impossible to use for any security purpose. I understand the challenge. Some of the container managers share namespaces between containers. Leading to things that are not really contained. Please make this concept like an indellibale die. Once you are stained with it you can not escape. If you don't meet all of the criteria you aren't stained. The justification that I heard, and that seems legitimate is that it is not timely and it is hard to make the connection between the distinct unshare, setns, and clone events and what is happening in the kernel. With that justification definitely the network namespace needs to be stained if it is appropriate. I also don't see why this can't be a special dedicated audit message. I just looked at the code in the kernel and nlmsg_type is a u16. There are only a handful of audit message types defined. There is absolutely no reason to bring proc into this. I have the same reservation as the others about defining a new cap for this. It should be enough to make setting the container id a one time thing for a set of processes and namespaces. If this is going to be security it needs to be very simple and very well defined. Eric