From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754026AbdJSQZw (ORCPT ); Thu, 19 Oct 2017 12:25:52 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:36119 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751217AbdJSQZs (ORCPT ); Thu, 19 Oct 2017 12:25:48 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Paul Moore Cc: Aleksa Sarai , James Bottomley , cgroups@vger.kernel.org, mszeredi@redhat.com, Andy Lutomirski , jlayton@redhat.com, "Carlos O'Donell" , API , Linux Containers , Linux Kernel , Viro , David Howells , Linux FS Devel , linux-audit@redhat.com, Simo Sorce , Development , Casey Schaufler , Eric Paris , Steve Grubb , trondmy@primarydata.com References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com> <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca> <2319693.5l3M4ZINGd@x2> <1508243469.6230.24.camel@redhat.com> <1508254120.6230.34.camel@redhat.com> <1508255091.3129.27.camel@HansenPartnership.com> <49752b6f-8a77-d1e5-8acb-5a1eed0a992c@suse.de> <871sm0j7bm.fsf@xmission.com> Date: Thu, 19 Oct 2017 11:25:10 -0500 In-Reply-To: (Paul Moore's message of "Thu, 19 Oct 2017 11:36:39 -0400") Message-ID: <87y3o7gl5l.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=1e5DdZ-0001VB-RI;;;mid=<87y3o7gl5l.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.233.18;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19cI46/KUKIZWpgg0lvTY9u9f/XRBtpfkU= 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 * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Paul Moore X-Spam-Relay-Country: X-Spam-Timing: total 5736 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 3.5 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 0.89 (0.0%), extract_message_metadata: 18 (0.3%), get_uri_detail_list: 2.0 (0.0%), tests_pri_-1000: 9 (0.2%), tests_pri_-950: 1.19 (0.0%), tests_pri_-900: 1.05 (0.0%), tests_pri_-400: 27 (0.5%), check_bayes: 26 (0.5%), b_tokenize: 9 (0.2%), b_tok_get_all: 9 (0.2%), b_comp_prob: 2.8 (0.0%), b_tok_touch_all: 3.0 (0.1%), b_finish: 0.59 (0.0%), tests_pri_0: 542 (9.5%), check_dkim_signature: 0.55 (0.0%), check_dkim_adsp: 234 (4.1%), tests_pri_500: 5130 (89.4%), poll_dns_idle: 5120 (89.3%), 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paul Moore writes: > On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman > wrote: >> Aleksa Sarai writes: >>>>> The security implications are that anything that can change the label >>>>> could also hide itself and its doings from the audit system and thus >>>>> would be used as a means to evade detection. I actually think this >>>>> means the label should be write once (once you've set it, you can't >>>>> change it) ... >>>> >>>> Richard and I have talked about a write once approach, but the >>>> thinking was that you may want to allow a nested container >>>> orchestrator (Why? I don't know, but people always want to do the >>>> craziest things.) and a write-once policy makes that impossible. If >>>> we punt on the nested orchestrator, I believe we can seriously think >>>> about a write-once policy to simplify things. >>> >>> Nested containers are a very widely used use-case (see LXC system containers, >>> inside of which people run other container runtimes). So I would definitely >>> consider it something that "needs to be supported in some way". While the LXC >>> guys might be a *tad* crazy, the use-case isn't. :P > > No worries, we're all a little crazy in our own special ways ;) > > Kidding aside, thanks for explaining the use case. > >> Of course some of that gets to running auditd inside a container which >> we don't have yet either. >> >> So I think to start it is perfectly fine to figure out the non-nested >> case first and what makes sense there. Then to sort out the nested >> container case. >> >> The solution might be that a process gets at most one id per ``audit >> namespace''. > > In an attempt to stay on-topic, let's try to stick with "audit > container ID" or "container ID" if you must. I really want to avoid > the term "audit namespace" simply because the term "namespace" implies > some things which we aren't planning on doing. This is 100% on topic. I am saying that unless we are planing to have auditd running in a container with it's own set of rules you probably don't care about nested containers. Last time I heard a discussion about that the term in use was audit namespace. So I was referring to that support when I said audit namespace, even if the end result only loosely fits the term namespace. I could be wrong of course. I don't fully understand what is driving the desire to connect audit and containers. But my naive guess is that one from an audit perspective you don't care about nested containers unless there is also a nested auditd who is looking at it from a nested perspective. So far we have established with the term container that we are talking about a running instance of processes, not a filesystem instance that Docker and friends ship around. Beyond that I am not certain what you care about. Eric