Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933562AbbENQWL (ORCPT ); Thu, 14 May 2015 12:22:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46804 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752443AbbENQWJ (ORCPT ); Thu, 14 May 2015 12:22:09 -0400 From: Steve Grubb To: "Eric W. Biederman" 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 Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances Date: Thu, 14 May 2015 12:21:53 -0400 Message-ID: <3156096.4s7Ni5U1tG@x2> Organization: Red Hat User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <87iobvnp1t.fsf@x220.int.ebiederm.org> References: <2918460.dpKocsKt4o@x2> <87iobvnp1t.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2519 Lines: 55 On Thursday, May 14, 2015 10:42:38 AM Eric W. Biederman wrote: > 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. Global to a name space for me is I guess relative for you. The ID is needed to tie events together to check for violations of the security policy of the container/namespace invoking child container/namespace. As a concrete example, suppose a container is to have its own /etc/shadow. If for some reason the container used the host's copy, then that would point to a misconfiguration or perhaps indicate an escape from the container. I would imagine that the next layer down has its own set of global identifiers so that it can verify enforcement of its own security assumptions. This does not need to be global to the system from top to 9 layers down. Each layer needs to have a way of locating events common to a child container instance. > I am sorry that isn't going to happen. EVER. Then I'd suggest we either scrap this set of patches and forget auditing of containers. (This would have the effect of disallowing them in a lot of environments because violations of security policy can't be detected.) Or someone please explain how what is proposed to be logged allows the tying together of events. Or even supports the requirements I stated in my last email. -Steve -- 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/