From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758240AbdJRAXO (ORCPT ); Tue, 17 Oct 2017 20:23:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57504 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754578AbdJRAXM (ORCPT ); Tue, 17 Oct 2017 20:23:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B648A12B98 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=sgrubb@redhat.com From: Steve Grubb To: James Bottomley Cc: Casey Schaufler , mszeredi@redhat.com, David Howells , Andy Lutomirski , jlayton@redhat.com, "Carlos O'Donell" , Linux API , Linux Containers , Linux Kernel , Eric Paris , linux-audit@redhat.com, "Eric W. Biederman" , Simo Sorce , cgroups@vger.kernel.org, Linux FS Devel , trondmy@primarydata.com, Linux Network Development , Al Viro Subject: Re: RFC(v2): Audit Kernel Container IDs Date: Tue, 17 Oct 2017 20:23:01 -0400 Message-ID: <16761682.puRDTGPHq7@x2> Organization: Red Hat In-Reply-To: <1508263063.3129.35.camel@HansenPartnership.com> References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <1982291.vr6V9CPzqu@x2> <1508263063.3129.35.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 18 Oct 2017 00:23:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, October 17, 2017 1:57:43 PM EDT James Bottomley wrote: > > > > The idea is that processes spawned into a container would be > > > > labelled by the container orchestration system. It's unclear > > > > what should happen to processes using nsenter after the fact, but > > > > policy for that should be up to the orchestration system. > > > > > > I'm fine with that. The user space policy can be anything y'all > > > like. > > > > I think there should be a login event. > > I thought you wanted this for containers? Container creation doesn't > have login events. In an unprivileged orchestration system it may be > hard to synthetically manufacture them. I realize this. This work is very similar to problems we've solved 12 years ago. We'll figure out what the right name is for it down the road. But the concept is the same. If something enters a container, we need to know about it. It needs to get tagged and be associated with the container. The way this was solved for the loginuid problem was to add a session identifier so that new logins of the same loginuid can coexist and we can trace actions back to a specific login. I'd think we can apply lessons learned from a while back to make container identification act similarly. -Steve