RFE: implement an audit container identifier

[rgbriggs]

Split this off from #32, leaving that issue for addressing namespace identifiers in audit records, should they be deemed necessary.

Implement an audit container identifier.

Add the ability to identify a task's assigned container using an audit container identifier. The registration process involves writing a u64 to file audit_containerid in the /proc filesystem under the PID of the target container task. This will result in a CONTAINER_ID record to log the event. Subsequent audit events that involve this task will have an auxiliary record CONTAINER to identify the container involved.

Depends: linux-audit/audit-userspace#51
See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID

History:

• Here's a patchset from David Howells that makes an attempt at a kernel container object that would have been useful for our use case:
  https://lkml.org/lkml/2017/5/22/645
• The LWN article reviewing it:
  https://lwn.net/Articles/723561/
• Posted Audit Kernel Container identifier proposal v1 upstream:
  https://www.redhat.com/archives/linux-audit/2017-September/msg00082.html
  https://lkml.org/lkml/2017/9/13/383
• Posted RFC(v2): Audit Kernel Container IDs proposal
  https://lkml.org/lkml/2017/10/12/354
• "non-Cc:" fork https://lkml.org/lkml/2017/10/17/689
• LWN coverage: https://lwn.net/Articles/740621/
• Posted RFC(v3): Audit Kernel Container identifiers proposal
  https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html
  https://lkml.org/lkml/2018/1/9/347
• Posted RFC v1 patchset upstream:
  https://lkml.org/lkml/2018/3/1/813
  https://www.redhat.com/archives/linux-audit/2018-March/msg00004.html
• Posted RFC v1 userspace patch for auditctl containerid filter support:
  https://www.redhat.com/archives/linux-audit/2018-March/msg00030.html
  https://lkml.org/lkml/2018/3/5/82
• Posted v2 patchset upstream:
  https://www.redhat.com/archives/linux-audit/2018-March/msg00110.html
  https://lkml.org/lkml/2018/3/16/191
• Posted v2 userspace patchset upstream:
  https://www.redhat.com/archives/linux-audit/2018-March/msg00124.html
  https://lkml.org/lkml/2018/3/16/210

[rgbriggs]

Posted v3 kernel patchset upstream:
https://www.redhat.com/archives/linux-audit/2018-June/msg00048.html
https://lkml.org/lkml/2018/6/6/609

[rgbriggs]

posted v4 kernel patchset upstream:
https://www.redhat.com/archives/linux-audit/2018-July/msg00178.html
https://lkml.org/lkml/2018/7/31/855

[nhorman]

I have a question regarding the container id assignment mechanism. Curently the patch in the v4 posted series loosely defines a container by virtue of the fact that a nonce is assigned to it from user space. This is nice for a few reasons, primarily because it excuses the kernel from having to have any definition of what a container is (ostensibly we consider a container to be a unique collection of namespaces, and possibly cgroups, but the kernel wants no knowledge of that). It seems this implementation of container assignment suffers from a few shortcommings however:

1. There appears to be no mechanism that prevents a container from modifying its own id (presuming CAP_SYS_ADMIN is not removed from its capability set, which I think doesn't occur for trusted containers)
2. There appears to be no mechanism for preventing a container from changing namespaces once an id is set for it, meaning that the correlation between the id and whatever you want to define in userspace as being a 'container' is lost
3. There is no current mechanism that prevents multiple unique 'containers' from sharing an id

All of these problems are of course fixable in the current implementation, but for the sake of argument, I'd like to propose an alternate solution that may (I've not 100% thought it out yet) reduce the complexity of the code, make the semantics of the control of the container id from userspace more clear, and solve the above problems

To start, I'd like to define (from a userspace perspective strictly) what we see as a container:

A container is defined by user space as a process that have a specific collection of (namespaces and cgroups) AND does NOT have the abilty to enter new namespaces and cgroups

I would propose that we implement the following in the kernel to enforce that policy:

1. Create a new capability, CAP_AUDIT_SETNS, which gates the ability to successfully call the setns system call. This capability is inherited by its children. If CAP_AUDIT_SETNS is re-granted to a process, its contid (see 2, below), is reset to AUDIT_CID_UNSET).

2. Create a new field in the audit struct per task, contid (which exists in this patchset already). This field is assigned a nonce (likely using the ida_simple_get api) if the CAP_AUDIT_SETNS capability is dropped, which would also generate an audit log message (simmilar to the one generated in audit_set_contid)

3. If a process calls fork/clone with any of the CLONE_ flag set, the CAP_AUDIT_SETNS capability is restored to the child process, and its contid value is reset to AUDIT_CID_UNSET (allowing for a process in a container to start a new container, but not to change its own 'container nature')

I think this approach may have a few advantages:
a) It provides a established mechanism (the capabilities subsystem), to provide a gated point at which the above container definition becomes locked from the perspective of the initial process inside the container. While the parent may re-grant the privlidge, it creates an environment whereby dropping the capability both locks the nature of what the container is (a unique set of namespaces and cgroups), and provides a unique id to the container for audit purposes

b) It removes the need to manage container id's from userspace, reducing the risk for errors in assigning duplicate identifiers, and reduces code size by removing the need to create a new proc file and validate the information passed through it.

c) It reduces complexity in the kernel code. The kernel can guarantee unique identifiers using the gating CAP_AUDIT_SETNS flag as the moment to generate the id.

This also (may) smooth upstream acceptace, because from a kernel standpoint, all we're doing is adding a capability to an established interface, and generating a nonce for the purposes of audit on the dropping of that capability. From user space its nice because we can consider the dropping of the ability to enter a new namespace as the border between a process being outside of, and inside of, a container.

We may have already gone down the path of the existing implementation to consider a change of this magnitude, but I wanted to bring this up before we were locked into a design