Paul Moore [off-list ref] writes:

On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh [off-list ref] wrote:

quoted

On 05/15/2015 05:05 PM, Paul Moore wrote:

quoted

On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:

quoted

On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs [off-list ref] wrote:

quoted

On 15/05/14, Paul Moore wrote:

quoted

* Look at our existing audit records to determine which records should
have
namespace and container ID tokens added.  We may only want to add the
additional fields in the case where the namespace/container ID tokens are
not the init namespace.

If we have a record that ties a set of namespace IDs with a container
ID, then I expect we only need to list the containerID along with auid
and sessionID.

The problem here is that the kernel has no concept of a "container", and I
don't think it makes any sense to add one just for audit.  "Container" is a
marketing term used by some userspace tools.

I can imagine that both audit could benefit from a concept of a
namespace *path* that understands nesting (e.g. root/2/5/1 or
something along those lines).  Mapping these to "containers" belongs
in userspace, I think.

It might be helpful to climb up a few levels in this thread ...

I think we all agree that containers are not a kernel construct.  I further
believe that the kernel has no business generating container IDs, those should
come from userspace and will likely be different depending on how you define
"container".  However, what is less clear to me at this point is how the
kernel should handle the setting, reporting, and general management of this
container ID token.

Wouldn't the easiest thing be to just treat add a containerid to the
process context like auid.

I believe so.  At least that was the point I was trying to get across
when I first jumped into this thread.

It sounds nice but containers are not just a per process construct.
Sometimes you might know anamespace but not which process instigated
action to happen on that namespace.

quoted

Then make it a privileged operation to set it.  Then tools that care about
auditing like docker can set the ID
and remove the Capability from it sub processes if it cares.  All
processes adopt parent processes containerid.
Now containers can be audited and as long as userspace is written
correctly nested containers can either override the containerid or not
depending on what the audit rules are.

This part I'm still less certain on.  I agree that setting the
container ID should be privileged in some sense, but the kernel
shouldn't *require* privilege to create a new container (however the
user chooses to define it).  Simply requiring privilege to set the
container ID and failing silently may be sufficient.

My hope is as things mature fewer and fewer container things will need
any special privilege to create.

I think it needs to start with a clear definition of what is wanted and
then working backwards through which messages in which contexts you want
to have your magic bits.

Eric