Add enforcement of sending signals to arbitrary processes in a container #1525
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Most people tend to think of a container as thing that does a single thing and by extension, as a thing that is a single process. This isn't the case but it is the mental model that people bring to containers. It also happens to be an incredibly common scenario where a container "equals" a single process. Our model for representing "container constraints" in the policy engine in GCS doesn't break out the init process of a container into a process representation. Instead, signals going to an init process are represented as signals "on the container" and signals going to other processes in the container are represented as signals on an "exec_process". This makes understanding how to apply constraints to a container easier for folks getting started with confidential containers. It also means that we need to have two different bits of code for enforcing signal constraints on processes in GCS. For any pid and container id combo we do the following: If the pid is for the init process of a container, then we know to use the container signal list for determining if sending the signal is allowed. If the pid isn't for an init process, then we have a bit more work to do. We don't have any mapping of a pid to policy entry if the pid isn't for the init process of a container. But, we can still map from the incoming pid to set of 0 or more valid policy exec_process entries. GCS stores a collection, on a per container basis, of all processes that were started including the OCI Spec for each process started. We can match the pid to the OCI Spec used to start the process with said pid. We can then use the command from that process to find any valid exec process entries in the policy for the container and see if any of them allow the signal in question. Any matching exec process entries can then be used to do further narrowing on possible container matches in the policy for the given container id. Signed-off-by: Sean T. Allen <seanallen@microsoft.com> Signed-off-by: Matthew A Johnson <matjoh@microsoft.com>
anmaxvl
reviewed
Sep 23, 2022
| @@ -467,6 +467,24 @@ func (h *Host) SignalContainerProcess(ctx context.Context, containerID string, p | |||
| return err | |||
| } | |||
|
|
|||
| signalingInitProcess := (processID == c.initProcess.pid) | |||
There was a problem hiding this comment.
we discussed this offline and will revisit this use case later. With current implementation, old behavior shouldn't change.
anmaxvl
approved these changes
Sep 23, 2022
dcantah
approved these changes
Sep 23, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most people tend to think of a container as thing that does a single thing and by extension, as a thing that is a single process. This isn't the case but it is the mental model that people bring to containers. It also happens to be an incredibly common scenario where a container "equals" a single process.
Our model for representing "container constraints" in the policy engine in GCS doesn't break out the init process of a container into a process representation. Instead, signals going to an init process are represented as signals "on the container" and signals going to other processes in the container are represented as signals on an "exec_process".
This makes understanding how to apply constraints to a container easier for folks getting started with confidential containers. It also means that we need to have two different bits of code for enforcing signal constraints on processes in GCS.
For any pid and container id combo we do the following:
If the pid is for the init process of a container, then we know to use the container signal list for determining if sending the signal is allowed.
If the pid isn't for an init process, then we have a bit more work to do. We don't have any mapping of a pid to policy entry if the pid isn't for the init process of a container. But, we can still map from the incoming pid to set of 0 or more valid policy exec_process entries.
GCS stores a collection, on a per container basis, of all processes that were started including the OCI Spec for each process started. We can match the pid to the OCI Spec used to start the process with said pid. We can then use the command from that process to find any valid exec process entries in the policy for the container and see if any of them allow the signal in question. Any matching exec process entries can then be used to do further narrowing on possible container matches in the policy for the given container id.