Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992449AbbEOVBh (ORCPT ); Fri, 15 May 2015 17:01:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40125 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935012AbbEOVBf (ORCPT ); Fri, 15 May 2015 17:01:35 -0400 From: Paul Moore To: "Eric W. Biederman" Cc: Steve Grubb , Richard Guy Briggs , containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-audit@redhat.com, eparis@parisplace.org, 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: Fri, 15 May 2015 17:01:25 -0400 Message-ID: <2432781.g45S2r75hS@sifl> Organization: Red Hat User-Agent: KMail/4.14.6 (Linux/3.16.7-gentoo; KDE/4.14.7; x86_64; ; ) In-Reply-To: <87bnhmbp8e.fsf@x220.int.ebiederm.org> References: <12675437.ssZNCck7zG@sifl> <87bnhmbp8e.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: 5070 Lines: 102 On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote: > Paul Moore writes: > > As Eric, and others, have stated, the container concept is a userspace > > idea, not a kernel idea; the kernel only knows, and cares about, > > namespaces. This is unlikely to change. > > > > However, as Steve points out, there is precedence for the kernel to record > > userspace tokens for the sake of audit. Personally I'm not a big fan of > > this in general, but I do recognize that it does satisfy a legitimate > > need. Think of things like auid and the sessionid as necessary evils; > > audit is already chock full of evilness I doubt one more will doom us all > > to hell. > > > > Moving forward, I'd like to see the following: > > > > * Create a container ID token (unsigned 32-bit integer?), similar to > > auid/sessionid, that is set by userspace and carried by the kernel to be > > used in audit records. I'd like to see some discussion on how we manage > > this, e.g. how do handle container ID inheritance, how do we handle > > nested containers (setting the containerid when it is already set), do we > > care if multiple different containers share the same namespace config, > > etc.? > > > > > > Can we all live with this? If not, please suggest some alternate ideas; > > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be > > true, but it doesn't help us solve the problem ;) > > Without stopping and defining what someone means by container I think it > is pretty much nonsense. For what it is worth, I doubt we will ever arrive at a consistent definition of a container. This is one of the reasons why I don't think we want the kernel generating a container ID token, although I understand the real world desire to have the kernel report such information back in the audit logs. > Should every vsftp connection get a container every? Every chrome tab? That's up to the individual system. I would argue that's a pretty silly configuration, but one persons silliness is another's best practice. It's a mad, mad world. > At some of the connections per second numbers I have seen we might > exhaust a 32bit number in an hour or two. Will any of that make sense > to someone reading the audit logs? If someone if going to spawn each process in a container then they will need to live with the fallout of that decision. Also, if folks thing 32-bits is too small, we can always do 64-bits, but I don't think that was the point you were trying to make (I could be wrong). > Without considerning that container creation is an unprivileged > operation I think it is pretty much nonsense. Do I get to say I am any > container I want? That would seem to invalidate the concept of > userspace setting a container id. > > How does any of this interact with setns? AKA entering a container? As I said in my email, I think we need some discussion around this; I don't pretend to think we have this sorted at this point. I just want to make sure were working towards some common ground instead of shouting the same stuff back and forth at each other. > I will go as far as looking at patches. If someone comes up with > a mission statement about what they are actually trying to achieve and a > mechanism that actually achieves that, and that allows for containers to > nest we can talk about doing something like that. I think Steve has posted some requirements that Richard is trying to satisfy with these patches; we've also heard from at least one person who is looking at how to deploy this in the Real World. Perhaps in the next round of patches Richard can list the requirements in the 0/X patch and describe how they are satisfied in the patchset. Beyond that, and ignoring for a moment the whole "a container is not a *thing*" argument, can I assume that the auditing of nested "containers" are your main remaining concern at this point? > But for right now I just hear proposals for things that make no sense > and can not possibly work. Not least because it will require modifying > every program that creates a container and who knows how many of them > there are. Especially since you don't need to be root. Modifying > /usr/bin/unshare seems a little far out to me. I think it is very reasonable that there will be some container infrastructure tools which would handle this, we're already seeing this happening now; asking for minor changes to these infrastructure applications to support container auditing doesn't seem like a significant ask to me. Also, to be perfectly clear, if the applications aren't updated it isn't as if they will fail to work, it is just that they won't be able to take advantage of the new container auditing capabilities. That seems reasonable to me. -- 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/