Thread (32 messages) 32 messages, 10 authors, 2017-12-11

Re: RFC(v2): Audit Kernel Container IDs

From: Steve Grubb <hidden>
Date: 2017-10-17 17:15:00
Also in: cgroups, linux-fsdevel, lkml, netdev

On Tuesday, October 17, 2017 12:43:18 PM EDT Casey Schaufler wrote:
quoted
The idea is that processes spawned into a container would be labelled
by the container orchestration system.  It's unclear what should happen
to processes using nsenter after the fact, but policy for that should
be up to the orchestration system.
I'm fine with that. The user space policy can be anything y'all like.
I think there should be a login event.

quoted
The label will be used as a tag for audit information.
Deep breath ...

Which *is* a kernel security policy mechanism. Since the "label"
is part of the audit information that the kernel is guaranteeing
changing it would be covered by CAP_AUDIT_CONTROL. If the kernel
does not use the "label" for any other purpose this is the only
capability that makes sense for it.
I agree. The ability to set the container label grants the ability to evade 
rules or modify audit rules. CAP_AUDIT_CONTROL makes sense to me.

quoted
I think you were missing label inheritance above.

The security implications are that anything that can change the label
could also hide itself and its doings from the audit system and thus
would be used as a means to evade detection.
Yes. We have the same problem with loginuid. There are restrictions on who can 
change it once set. And then we made an immutable flag so that people that 
want a hard guarantee can get that.

-Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help