Re: RFC(v2): Audit Kernel Container IDs
On Thursday, October 19, 2017 7:11:33 PM EDT Aleksa Sarai wrote:
>>> The registration is a pseudo filesystem (proc, since PID
tree already
>>> exists) write of a u8[16] UUID representing the container ID to a file
>>> representing a process that will become the first process in a new
>>> container. This write might place restrictions on mount namespaces
>>> required to define a container, or at least careful checking of
>>> namespaces in the kernel to verify permissions of the orchestrator so it
>>> can't change its own container ID. A bind mount of nsfs may be
>>> necessary in the container orchestrator's mntNS.
>>> Note: Use a 128-bit scalar rather than a string to make compares faster
>>> and simpler.
>>>
>>> Require a new CAP_CONTAINER_ADMIN to be able to carry out the
>>> registration.
>>
>> Wouldn't CAP_AUDIT_WRITE be sufficient? After all, this is for auditing.
>
> No, because then any process with that capability (vsftpd) could change
> its own container ID. This is discussed more in other parts of the
> thread...
For the record, I changed my mind. CAP_AUDIT_CONTROL is the correct
capability.
Not if we make the container ID append-only (to support nesting), or
write-once (the other idea thrown around).
Well...I like to use lessons learned if they can be applied. In the normal
world without containers we have uid, auid, and session_id. uid is who you are
now, auid is how you got into the system, session_id distinguishes individual
auids. We have a default auid of -1 for system objects and a real number for
people.
I think there should be the equivalent of auid and session_id but tailored for
containers. Loginuid == container id. It can be set, overridden, or appended
to (we'll figure this out later) in very limited circumstances.
Container_session == session which is tamper-proof. This way things can enter
a container with the same ID but under a different session. And everything
else gets to inherit the original ID. This way we can trace actions to
something that entered the container rather than normal system activity in the
container.
What a security officer wants to know is what did people do inside the
system / container. The system objects we typically don't care about. Sure
they might get hacked and then work on behalf of someone, but they would
almost always pop a shell so that they can have freedom. That should set off
an AVC or create other activity that gets picked up.
-Steve
In that case, you can't move "out" from a particular
container ID, you can
only go "deeper". These semantics don't make sense for generic containers,
but since the point of this facility is *specifically* for audit I imagine
that not being able to move a process from a sub-container's ID is a
benefit.