Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753786AbbEPMQ7 (ORCPT ); Sat, 16 May 2015 08:16:59 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:35012 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751299AbbEPMQ4 (ORCPT ); Sat, 16 May 2015 08:16:56 -0400 MIME-Version: 1.0 X-Originating-IP: [76.119.162.148] In-Reply-To: <555711FA.50703@redhat.com> References: <20150515023221.GC965@madcap2.tricolour.ca> <9125391.7ZiCneo6Xn@sifl> <555711FA.50703@redhat.com> Date: Sat, 16 May 2015 08:16:55 -0400 Message-ID: Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances From: Paul Moore To: Daniel J Walsh Cc: Paul Moore , Andy Lutomirski , "Serge E. Hallyn" , Richard Guy Briggs , Linux API , Linux Containers , "linux-kernel@vger.kernel.org" , Al Viro , linux-audit@redhat.com, "Eric W. Biederman" , Network Development , Linux FS Devel , Eric Paris 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: 2902 Lines: 58 On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh wrote: > On 05/15/2015 05:05 PM, Paul Moore wrote: >> 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. >> > Wouldn't the easiest thing be to just treat add a containerid to the > process context like auid. I believe so. At least that was the point I was trying to get across when I first jumped into this thread. > Then make it a privileged operation to set it. Then tools that care about > auditing like docker can set the ID > and remove the Capability from it sub processes if it cares. All > processes adopt parent processes containerid. > Now containers can be audited and as long as userspace is written > correctly nested containers can either override the containerid or not > depending on what the audit rules are. This part I'm still less certain on. I agree that setting the container ID should be privileged in some sense, but the kernel shouldn't *require* privilege to create a new container (however the user chooses to define it). Simply requiring privilege to set the container ID and failing silently may be sufficient. -- 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/