Re: RFC(V3): Audit Kernel Container IDs
On Tue, Jan 9, 2018 at 11:18 AM, Simo Sorce <simo(a)redhat.com> 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