Date: Thu, 14 May 2015 22:03:57 -0400
From: Richard Guy Briggs <rgb@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Steve Grubb <sgrubb@redhat.com>, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, linux-audit@redhat.com,
        eparis@parisplace.org, pmoore@redhat.com, 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
Message-ID: <20150515020357.GC10526@madcap2.tricolour.ca>
References: <cover.1429252659.git.rgb@redhat.com>
 <2487286.y6vyJ9A3er@x2>
 <20150512195759.GA9832@madcap2.tricolour.ca>
 <2918460.dpKocsKt4o@x2>
 <87iobvnp1t.fsf@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87iobvnp1t.fsf@x220.int.ebiederm.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3106
Lines: 69

On 15/05/14, Eric W. Biederman wrote:
> Steve Grubb <sgrubb@redhat.com> writes:
> > On Tuesday, May 12, 2015 03:57:59 PM Richard Guy Briggs wrote:
> >> On 15/05/05, Steve Grubb wrote:
> >> > I think there needs to be some more discussion around this. It seems like
> >> > this is not exactly recording things that are useful for audit.
> >> 
> >> It seems to me that either audit has to assemble that information, or
> >> the kernel has to do so.  The kernel doesn't know about containers
> >> (yet?).
> >
> > Auditing is something that has a lot of requirements imposed on it by security 
> > standards. There was no requirement to have an auid until audit came along and 
> > said that uid is not good enough to know who is issuing commands because of su 
> > or sudo. There was no requirement for sessionid until we had to track each 
> > action back to a login so we could see if the login came from the expected 
> > place. 
> 
> Stop right there.
> 
> You want a global identifier in a realm where only relative identifiers
> exist, and make sense.

I am assuming he wants an identifier unique per container on one kernel
and what happens on other kernels is a matter for a management
application to take care of.  This kernel doesn't have to deal with it
other than taking information from a container management application.

> I am sorry that isn't going to happen. EVER.
> 
> Square peg, round hole.  It doesn't work, it doesn't make sense, and
> most especially it doesn't allow anyone to reconstruct anything, because
> it does not make sense and does not match what the kernel is doing.
> 
> Container IDs do not, and will not exist.  There is probably something
> reasonable in your request but until you stop talking that nonsense I
> can't see it.

I didn't see anything in any of what Steve said that suggested it was to
be unique beyond that one kernel.

> Global IDs take us into the namespace of namespaces problem and that
> isn't going to happen.  I have already bent as far in this direction as
> I can go.  Further namespace creation is not a privileged event which
> makes the requestion for a container ID make even less sense.  With
> anyone able to create whatever they want it will not be a identifier
> that makes any sense to someone reading an audit log.

Again, I assume this is up to a container management application that
will manage its pool of container hosts and an audit aggregator.

You keep raising an objection about the unworkability of a "namespace of
namespaces".  Just so we are all on the same page here, can you explain
exactly what you mean with "namespace of namespaces"?

> Eric

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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/