Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965048AbbESO1k (ORCPT ); Tue, 19 May 2015 10:27:40 -0400 Received: from mail-ob0-f182.google.com ([209.85.214.182]:32971 "EHLO mail-ob0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933398AbbESO1g (ORCPT ); Tue, 19 May 2015 10:27:36 -0400 MIME-Version: 1.0 X-Originating-IP: [76.119.162.148] In-Reply-To: <20150519130911.GB20131@madcap2.tricolour.ca> References: <20150515023221.GC965@madcap2.tricolour.ca> <9125391.7ZiCneo6Xn@sifl> <555711FA.50703@redhat.com> <87r3qgpol6.fsf@x220.int.ebiederm.org> <20150519130911.GB20131@madcap2.tricolour.ca> Date: Tue, 19 May 2015 10:27:30 -0400 Message-ID: Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances From: Paul Moore To: Richard Guy Briggs Cc: "Eric W. Biederman" , Linux API , Linux Containers , "linux-kernel@vger.kernel.org" , Andy Lutomirski , linux-audit@redhat.com, Al Viro , Network Development , Linux FS Devel , Eric Paris , "Serge E. Hallyn" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1861 Lines: 38 On Tue, May 19, 2015 at 9:09 AM, Richard Guy Briggs wrote: > On 15/05/16, Paul Moore wrote: >> On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman wrote: >> > It sounds nice but containers are not just a per process construct. >> > Sometimes you might know anamespace but not which process instigated >> > action to happen on that namespace. >> >> From an auditing perspective I'm not sure we will ever hit those >> cases; did you have a particular example in mind? > > The example that immediately came to mind when I first read Eric's > comment was a packet coming in off a network in a particular network > namespace. That could narrow it down to a subset of containers based on > which network namespace it inhabits, but since it isn't associated with > a particular task yet (other than a kernel thread) it will not be > possible to select the precise nsproxy, let alone the container. Thanks, I was stuck thinking about syscall based auditing and forgot about the various LSM based audit records. Of all people you would think I would remember per-packet audit records ;) Anyway, in this case I think including the namespace ID is sufficient, largely because the container userspace doesn't have access to the packet at this point. In order to actually receive the data the container's userspace will need to issue a syscall where we can include the container ID. An overly zealous security officer who wants to trace all the kernel level audit events, like the one you describe, can match up the namespace to a container in post-processing if needed. -- paul moore www.paul-moore.com -- 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/