From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751634AbdJSAoG (ORCPT ); Wed, 18 Oct 2017 20:44:06 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:46156 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbdJSAoC (ORCPT ); Wed, 18 Oct 2017 20:44:02 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Aleksa Sarai Cc: Paul Moore , 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> Date: Wed, 18 Oct 2017 19:43:25 -0500 In-Reply-To: <49752b6f-8a77-d1e5-8acb-5a1eed0a992c@suse.de> (Aleksa Sarai's message of "Thu, 19 Oct 2017 10:46:18 +1100") Message-ID: <871sm0j7bm.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=1e4ywC-0004Xo-0y;;;mid=<871sm0j7bm.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.233.18;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/cNDlJ07ELnshyKV+WdYhIjzo7s9+HeiE= 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 * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Aleksa Sarai X-Spam-Relay-Country: X-Spam-Timing: total 5309 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.4 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 1.39 (0.0%), extract_message_metadata: 16 (0.3%), get_uri_detail_list: 1.66 (0.0%), tests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.61 (0.0%), tests_pri_-900: 1.33 (0.0%), tests_pri_-400: 27 (0.5%), check_bayes: 26 (0.5%), b_tokenize: 10 (0.2%), b_tok_get_all: 8 (0.1%), b_comp_prob: 2.7 (0.1%), b_tok_touch_all: 3.1 (0.1%), b_finish: 0.75 (0.0%), tests_pri_0: 1329 (25.0%), check_dkim_signature: 0.83 (0.0%), check_dkim_adsp: 4.8 (0.1%), tests_pri_500: 3918 (73.8%), poll_dns_idle: 3910 (73.6%), 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 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 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''. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: RFC(v2): Audit Kernel Container IDs Date: Wed, 18 Oct 2017 19:43:25 -0500 Message-ID: <871sm0j7bm.fsf@xmission.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> Mime-Version: 1.0 Content-Type: text/plain Cc: Paul Moore , James Bottomley , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Andy Lutomirski , jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Carlos O'Donell , API , Linux Containers , Linux Kernel , Viro , David Howells , Linux FS Devel , linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Simo Sorce , Development , Casey Schaufler , Eric Paris , Steve Grubb , trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org To: Aleksa Sarai Return-path: In-Reply-To: <49752b6f-8a77-d1e5-8acb-5a1eed0a992c-l3A5Bk7waGM@public.gmane.org> (Aleksa Sarai's message of "Thu, 19 Oct 2017 10:46:18 +1100") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org 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 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''. Eric