On 4/18/2018 5:46 PM, Paul Moore wrote:

On Wed, Apr 18, 2018 at 8:41 PM, Casey Schaufler [off-list ref] wrote:

quoted

On 4/18/2018 4:47 PM, Paul Moore wrote:

quoted

On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs [off-list ref] wrote:

quoted

Implement the proc fs write to set the audit container ID of a process,
emitting an AUDIT_CONTAINER record to document the event.
...

diff --git a/include/linux/sched.h b/include/linux/sched.h
index d258826..1b82191 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h

@@ -796,6 +796,7 @@ struct task_struct {
 #ifdef CONFIG_AUDITSYSCALL
        kuid_t                          loginuid;
        unsigned int                    sessionid;
+       u64                             containerid;

This one line addition to the task_struct scares me the most of
anything in this patchset.  Why?  It's a field named "containerid" in
a perhaps one of the most widely used core kernel structures; the
possibilities for abuse are endless, and it's foolish to think we
would ever be able to adequately police this.

If we can get the LSM infrastructure managed task blobs from
module stacking in ahead of this we could create a trivial security
module to manage this. It's not as if there aren't all sorts of
interactions between security modules and the audit system already.

While yes, there are plenty of interactions between the two, it is
possible to use audit without the LSMs and I would like to preserve
that.  

Fair enough.

Further, I don't want to entangle two very complicated code
changes or make the audit container ID effort dependent on LSM
stacking.

Also fair, although the use case for container audit IDs is
already pulling in audit, namespaces (yeah, I know it's not
necessary for a container to use namespaces) security modules
(stacked and/or namespaced), cgroups and who knows what else.

You're a good salesman Casey, but you're not that good ;)

I have to keep the skills sharpened somehow!

OK, I'll grant that this isn't a great fit.