[WIP] Add ambient capabilities gated by no new privileges #30382
Conversation
This file contains hidden or 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
justincormack
added
status/1-design-review
impact/changelog
impact/documentation
and removed
status/0-triage
labels
justincormack
force-pushed
the
nnp-ambient
branch
2 times, most recently
from
1d7d6c0 to
4aec932
Compare
This is a rework of support for ambient capabilities, to avoid the issues in the previous version, where there was a conflict between two use cases, programs that want to use sudo and programs that want to grant unprivileged users direct capabilities. If you do not use the `--security-opt no-new-privileges` flag, nothing changes with this patch. `sudo`, suid binaries and filesystem capabilities elevate privileges, and non root users can only use privileges via these mechanisms as on a normal Linux userspace. With the `no-new-privileges` flag, the kernel does not allow caps to be granted via suid binaries, so it is assumed that the user wants to be granted capabilities directly, so ambient capabilities are granted. For root this makes little difference, but for a normal user this means that they can be granted capabilities directly, so that privileged operations can be performed directly. As previously no capabilities were granted to a non root user with `no-new-privileges`, we take the opoprtunity to reduce the default capability set in this case to only the three safest capabilities: `CAP_KILL`, `CAP_AUDIT_WRITE` and `CAP_NET_SERVICE`. Other capabilities must be granted with `--cap-add`. `runc` commit is in opencontainers/runc#1286 Spec commit is in opencontainers/runtime-spec#668 fix moby#8460 Signed-off-by: Justin Cormack <[email protected]>
justincormack
force-pushed
the
nnp-ambient
branch
from
4aec932 to
5d22eae
Compare
Contributor
Author
|
cc @jessfraz as you like to use no new privileges, how about some capabilities with that? |
Contributor
Author
|
I am going to close this as it looks like OCI is not going to take this spec change as is, will leave this branch for anyone who wants to test, and redo if/when the spec is finalised... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This is a rework of support for ambient capabilities, to avoid
the issues in the previous version, where there was a conflict
between two use cases, programs that want to use sudo and programs
that want to grant unprivileged users direct capabilities.
If you do not use the
--security-opt no-new-privilegesflag,nothing changes with this patch.
sudo, suid binaries and filesystemcapabilities elevate privileges, and non root users can only use
privileges via these mechanisms as on a normal Linux userspace.
With the
no-new-privilegesflag, the kernel does not allow capsto be granted via suid binaries, so it is assumed that the user wants
to be granted capabilities directly, so ambient capabilities are
granted. For root this makes little difference, but for a normal
user this means that they can be granted capabilities directly, so
that privileged operations can be performed directly.
As previously no capabilities were granted to a non root user with
no-new-privileges, we take the opoprtunity to reduce the defaultcapability set in this case to only the three safest capabilities:
CAP_KILL,CAP_AUDIT_WRITEandCAP_NET_SERVICE. Other capabilitiesmust be granted with
--cap-add.runccommit is in opencontainers/runc#1286Spec commit is in opencontainers/runtime-spec#668
These upstream commits need merging first so marked as WIP, but this allows people to test.
fix #8460
See #26979 for previous version.
Signed-off-by: Justin Cormack [email protected]