On Tue, Jan 9, 2018 at 11:18 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote: ... >> Changelog: >> >> (Upstream V3) >> - switch back to u64 (from pmoore, can be expanded to u128 in future if >> need arises without breaking API. u32 was originally proposed, up to >> c36 discussed) >> - write-once, but children inherit audit container identifier and can >> then still be written once >> - switch to CAP_AUDIT_CONTROL >> - group namespace actions together, auxilliary records to namespace >> operations. >> >> (Upstream V2) >> - switch from u64 to u128 UUID >> - switch from "signal" and "trigger" to "register" >> - restrict registration to single process or force all threads and >> children into same container > > I am trying to understand the back and forth on the ID size. I'm just now getting a chance to read Richard's latest draft, but I wanted to comment on this quickly. There are two main reasons for keeping this a 32 or 64 bit integer: 1) After the initial "be able to associate audit events with a container" stage, we are going to look into supporting multiple audit daemons on the system so that you could run an audit daemon inside a container and it would collect events generated by the container (we're tentatively calling this "phase 2", feel free to insert your own "magic happens" joke). There are a lot things that need to happen in phase two, one of these things is the addition of an audit event routing mechanism that will send audit records to the right audit daemons (the "host" daemon will always see everything), in order to do this we will need to be able to quickly compare audit container IDs, this means an integer. 2) Whatever we pick for an audit container ID it is going to be wrong for at least one container orchestrator. There is no "one" solution here, so we are providing a small and flexible mechanism that higher level orchestrators can use to provide a more complete solution. > >From an orchestrator POV anything that requires tracking a node > specific ID is not ideal. > > Orchestrators tend to span many nodes, and containers tend to have IDs > that are either UUID or have a Hash (like SHA256) as identifier. You're helping me prove my reason #2. > The problem here is two-fold: > > a) Your auditing requires some mapping to be useful outside of the > system. > If you aggreggate audit logs outside of the system or you want to > correlate the system audit logs with other components dealing with > containers, now you need a place where you provide a mapping from your > audit u64 to the ID a container has in the rest of the system. Yep, see my reason #2. I want us to have something that "works" for a single system as well as something that can be leveraged by higher level tools for large networks of machines. I realize it's easy, and tempting, to expand the scope of this effort; but if we are to have any success it is only going to be through some discipline. We need to focus on a small solution which addresses the basic needs and hopefully remains flexible enough for any potential expansion while staying palatable to the audit folks and the general kernel community. > b) Now you need a mapping of some sort. The simplest way a container > orchestrator can go about this is to just use the UUID or Hash > representing their view of the container, truncate it to a u64 and use > that for Audit. This means there are some chances there will be a > collision and a duplicate u64 ID will be used by the orchestrator as > the container ID. What happen in that case ? That is a design decision left to the different container orchestrators. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
