Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030232AbbENPre (ORCPT ); Thu, 14 May 2015 11:47:34 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:60035 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933660AbbENPra (ORCPT ); Thu, 14 May 2015 11:47:30 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Steve Grubb Cc: Richard Guy Briggs , containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-audit@redhat.com, eparis@parisplace.org, pmoore@redhat.com, arozansk@redhat.com, serge@hallyn.com, zohar@linux.vnet.ibm.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, netdev@vger.kernel.org References: <2487286.y6vyJ9A3er@x2> <20150512195759.GA9832@madcap2.tricolour.ca> <2918460.dpKocsKt4o@x2> Date: Thu, 14 May 2015 10:42:38 -0500 In-Reply-To: <2918460.dpKocsKt4o@x2> (Steve Grubb's message of "Thu, 14 May 2015 10:57:14 -0400") Message-ID: <87iobvnp1t.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX193g6MGZ7Ogl0IONAJz7xBS6ogILvdOauk= X-SA-Exim-Connect-IP: 67.3.205.90 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 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: ;Steve Grubb X-Spam-Relay-Country: X-Spam-Timing: total 336 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.2 (1.0%), b_tie_ro: 2.3 (0.7%), parse: 0.71 (0.2%), extract_message_metadata: 3.0 (0.9%), get_uri_detail_list: 1.34 (0.4%), tests_pri_-1000: 3.7 (1.1%), tests_pri_-950: 1.29 (0.4%), tests_pri_-900: 1.10 (0.3%), tests_pri_-400: 21 (6.3%), check_bayes: 20 (6.0%), b_tokenize: 6 (1.7%), b_tok_get_all: 8 (2.3%), b_comp_prob: 2.2 (0.6%), b_tok_touch_all: 2.5 (0.8%), b_finish: 0.61 (0.2%), tests_pri_0: 289 (86.0%), tests_pri_500: 3.7 (1.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -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 Content-Length: 2043 Lines: 46 Steve Grubb writes: > On Tuesday, May 12, 2015 03:57:59 PM Richard Guy Briggs wrote: >> On 15/05/05, Steve Grubb wrote: >> > I think there needs to be some more discussion around this. It seems like >> > this is not exactly recording things that are useful for audit. >> >> It seems to me that either audit has to assemble that information, or >> the kernel has to do so. The kernel doesn't know about containers >> (yet?). > > Auditing is something that has a lot of requirements imposed on it by security > standards. There was no requirement to have an auid until audit came along and > said that uid is not good enough to know who is issuing commands because of su > or sudo. There was no requirement for sessionid until we had to track each > action back to a login so we could see if the login came from the expected > place. Stop right there. You want a global identifier in a realm where only relative identifiers exist, and make sense. I am sorry that isn't going to happen. EVER. Square peg, round hole. It doesn't work, it doesn't make sense, and most especially it doesn't allow anyone to reconstruct anything, because it does not make sense and does not match what the kernel is doing. Container IDs do not, and will not exist. There is probably something reasonable in your request but until you stop talking that nonsense I can't see it. Global IDs take us into the namespace of namespaces problem and that isn't going to happen. I have already bent as far in this direction as I can go. Further namespace creation is not a privileged event which makes the requestion for a container ID make even less sense. With anyone able to create whatever they want it will not be a identifier that makes any sense to someone reading an audit log. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/