On 4/18/2018 5:46 PM, Paul Moore wrote:
On Wed, Apr 18, 2018 at 8:41 PM, Casey Schaufler
<casey(a)schaufler-ca.com> wrote:
> On 4/18/2018 4:47 PM, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs <rgb(a)redhat.com>
wrote:
>>> 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.