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.
