-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for mount policy enforcement. #1311
Conversation
54491be
to
caa48aa
Compare
I worry about the handcrafted nature of the test coverage for the functionality. There's a ton of options and a large number of interleavings that probably aren't covered. I'd personally feel more confident if there were generative tests to cover all the edges. That said, I can imagine that writing them would be a pain as would understanding them without copious comments. Do any of the existing unit tests cover this functionality or is it only the new functional test(s) that provide coverage? |
@SeanTAllen , I haven't added any unit tests, only the e2e functional ones. I'll get to the unit tests later. |
3294385
to
e6966f5
Compare
69beb99
to
2dbf0a0
Compare
ed88272
to
ead70b4
Compare
0b942d6
to
8c92072
Compare
a0536ce
to
15afe54
Compare
You have a merge conflict FYI |
15afe54
to
0ed9bd0
Compare
done resolving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small comment or so, but otherwise lgtm
0ed9bd0
to
679bf8c
Compare
@@ -133,19 +190,28 @@ func NewStandardSecurityPolicyEnforcer(containers []securityPolicyContainer, enc | |||
func (c Containers) toInternal() ([]securityPolicyContainer, error) { | |||
containerMapLength := len(c.Elements) | |||
if c.Length != containerMapLength { | |||
return nil, fmt.Errorf("container numbers don't match in policy. expected: %d, actual: %d", c.Length, containerMapLength) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general comment, if you have two sets of changes, things that are really important, and some general cleanup that is not important, it can be helpful to put them in separate PRs. That way it's easier for reviewers to focus on the really important part of the changes. This can be especially helpful with GitHub since it's so bad at just showing you the new pieces of a PR that you've looked at already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't necessarily need to do that here, since it's been around for a while already, but good to consider in the future.
It is possible that a malicious mount can be used to attack an LCOW pod. If the attacker has knowleldge of the workload running, they could possibly change the environment for a container and alter its execution. This PR adds support for describing and enforcing mount policy for a given container. The mount policy closely follows OCI spec to be as explicit as possible to the user. The policy can be made less explicit in the future if needed. The dev tool has been updated to support mount configurations and the configuration spec is similar to CRI config with the exception of unsupported features (e.g., selinux config). The tool translates CRI config to appropriate mount type and options in mount policy. Initial implementation doesn't support any wildcards for the Destination, but supports REGEX for the Source. CRI adds some default mounts for all Linux containers and they had to be hardcoded in this codebase as well. Extra caution is needed in the future, in case the list expands. Additional changes have been made to how sandbox and hugepages mounts are generated to make sure that the same utility functions are used to generate appropriate mount specs. Add positive and negative tests for security policy mount constraints Hide mount enforcement behind a LCOWIntegrity feature flag Update securitypolicy tool docs Signed-off-by: Maksim An <[email protected]>
6a15f78
to
682b056
Compare
Signed-off-by: Maksim An <[email protected]>
682b056
to
2af6ba2
Compare
@kevpar moved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…)" This reverts commit 2028de8. During local testing a gcs with an older version of security policy was used when doing the fix: microsoft#1322. As we can see, the quotations weren't there. However, later a PR was merged, which added them: microsoft#1311 Signed-off-by: Maksim An <[email protected]>
This reverts commit 2028de8. During local testing a gcs with an older version of security policy was used when doing the fix: #1322. As we can see, the quotations weren't there. However, later a PR was merged, which added them: #1311 Signed-off-by: Maksim An <[email protected]>
* Add support for mount policy enforcement. It is possible that a malicious mount can be used to attack an LCOW pod. If the attacker has knowleldge of the workload running, they could possibly change the environment for a container and alter its execution. This PR adds support for describing and enforcing mount policy for a given container. The mount policy closely follows OCI spec to be as explicit as possible to the user. The policy can be made less explicit in the future if needed. The dev tool has been updated to support mount configurations and the configuration spec is similar to CRI config with the exception of unsupported features (e.g., selinux config). The tool translates CRI config to appropriate mount type and options in mount policy. Initial implementation doesn't support any wildcards for the Destination, but supports REGEX for the Source. CRI adds some default mounts for all Linux containers and they had to be hardcoded in this codebase as well. Extra caution is needed in the future, in case the list expands. Additional changes have been made to how sandbox and hugepages mounts are generated to make sure that the same utility functions are used to generate appropriate mount specs. Add positive and negative tests for security policy mount constraints Hide mount enforcement behind a LCOWIntegrity feature flag Update securitypolicy tool docs Signed-off-by: Maksim An <[email protected]>
It is possible that a malicious mount can be used to attack an LCOW pod.
If the attacker has knowleldge of the workload running, they could
possibly change the environment for a container and alter its execution.
This PR adds support for describing and enforcing mount policy for a
given container. The mount policy closely follows OCI spec to be as
explicit as possible to the user. The policy can be made less explicit
in the future if needed.
The dev tool has been updated to support mount configurations and the
configuration spec is similar to CRI config with the exception of
unsupported features (e.g., selinux config).
The tool translates CRI config to appropriate mount type and options in
mount policy. Initial implementation doesn't support any wildcards and
mount source and destinations are compared directly.
CRI adds some default mounts for all Linux containers and they had to be
hardcoded in this codebase as well. Extra caution is needed in the
future, in case the list expands.
Additional changes have been made to how sandbox and hugepages mounts
are generated to make sure that the same utility functions are used to
generate appropriate mount specs.
TODO:
Signed-off-by: Maksim An [email protected]