Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946136AbbEOVFa (ORCPT ); Fri, 15 May 2015 17:05:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56674 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422784AbbEOVFZ (ORCPT ); Fri, 15 May 2015 17:05:25 -0400 From: Paul Moore To: Andy Lutomirski Cc: Richard Guy Briggs , Steve Grubb , "Eric W. Biederman" , Linux Containers , "linux-kernel@vger.kernel.org" , linux-audit@redhat.com, Eric Paris , arozansk@redhat.com, "Serge E. Hallyn" , Mimi Zohar , Al Viro , Linux FS Devel , Linux API , Network Development Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances Date: Fri, 15 May 2015 17:05:24 -0400 Message-ID: <9125391.7ZiCneo6Xn@sifl> Organization: Red Hat User-Agent: KMail/4.14.6 (Linux/3.16.7-gentoo; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150515023221.GC965@madcap2.tricolour.ca> 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: 1802 Lines: 40 On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote: > On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs wrote: > > On 15/05/14, Paul Moore wrote: > >> * Look at our existing audit records to determine which records should > >> have > >> namespace and container ID tokens added. We may only want to add the > >> additional fields in the case where the namespace/container ID tokens are > >> not the init namespace. > > > > If we have a record that ties a set of namespace IDs with a container > > ID, then I expect we only need to list the containerID along with auid > > and sessionID. > > The problem here is that the kernel has no concept of a "container", and I > don't think it makes any sense to add one just for audit. "Container" is a > marketing term used by some userspace tools. > > I can imagine that both audit could benefit from a concept of a > namespace *path* that understands nesting (e.g. root/2/5/1 or > something along those lines). Mapping these to "containers" belongs > in userspace, I think. It might be helpful to climb up a few levels in this thread ... I think we all agree that containers are not a kernel construct. I further believe that the kernel has no business generating container IDs, those should come from userspace and will likely be different depending on how you define "container". However, what is less clear to me at this point is how the kernel should handle the setting, reporting, and general management of this container ID token. -- paul moore security @ redhat -- 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/