Skip to content
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

Need to setup labeling of kernel keyrings. #2012

Merged
merged 1 commit into from
Mar 21, 2019

Conversation

rhatdan
Copy link
Contributor

@rhatdan rhatdan commented Mar 13, 2019

Work is ongoing in the kernel to support different kernel
keyrings per user namespace. We want to allow SELinux to manage
kernel keyrings inside of the container.

Currently when runc creates the kernel keyring it gets the label which runc is
running with ususally container_runtime_t, with this change the kernel keyring
will be labeled with the container process label container_t:s0:C1,c2.

Container running as container_t:s0:c1,c2 can manage keyrings with the same label.

This change required a revendoring or the SELinux go bindings.

github.com/opencontainers/selinux.

Signed-off-by: Daniel J Walsh [email protected]

Work is ongoing in the kernel to support different kernel
keyrings per user namespace.  We want to allow SELinux to manage
kernel keyrings inside of the container.

Currently when runc creates the kernel keyring it gets the label which runc is
running with ususally `container_runtime_t`, with this change the kernel keyring
will be labeled with the container process label container_t:s0:C1,c2.

Container running as container_t:s0:c1,c2 can manage keyrings with the same label.

This change required a revendoring or the SELinux go bindings.

github.com/opencontainers/selinux.

Signed-off-by: Daniel J Walsh <[email protected]>
@rhatdan
Copy link
Contributor Author

rhatdan commented Mar 13, 2019

@giuseppe FYI

@@ -5,7 +5,7 @@ github.com/opencontainers/runtime-spec 29686dbc5559d93fb1ef402eeda3e35c38d75af4
# Core libcontainer functionality.
github.com/checkpoint-restore/go-criu v3.11
github.com/mrunalp/fileutils ed869b029674c0e9ce4c0dfa781405c2d9946d08
github.com/opencontainers/selinux v1.0.0-rc1
github.com/opencontainers/selinux v1.2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not directly related to this PR); I noticed that these tags miss a trailing .0, and because of that are following the SemVer syntax (which may complicate using them with Go mod)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add another .0 if necessary. in the next version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I noticed it earlier this week, and this PR made me remember that I saw that 🤗

@@ -48,6 +48,10 @@ func (l *linuxStandardInit) Init() error {
runtime.LockOSThread()
defer runtime.UnlockOSThread()
if !l.config.Config.NoNewKeyring {
if err := label.SetKeyLabel(l.config.ProcessLabel); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double-check -- are you sure this needs to be done before we create a new session? (Is SetKeyLabel setting what the label will be for all future keys or the label for the current key?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this says to the kernel, any new keyrings that get created by this process and its children should get created with the specified label.
When the new keyring gets created it gets created with the correct label.
Later on the defaulf SetKeyLabel("") tells the kernel to go back to the default labeling.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I have been testing this patch with the updated kernel, which allows sepate kernel keyrings for each new UserNamespace.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not clear why we need to reset it back. Shouldn't it pass down to the container process?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it will, the reset is on defer. Not really important for runc, but if people vendor in this code, then we would want to make sure other code paths don't accidently set the label to this container.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, we've discussed the defer handling for SELinux in the past. Even though it doesn't really make sense for runc it avoids people vendoring it and shooting themselves in the foot (not that SELinux is the only thing that is a massive foot-gun in libcontainer).

@cyphar
Copy link
Member

cyphar commented Mar 16, 2019

LGTM. I haven't tested on a kernel with keyring labeling support, but I take @rhatdan's word that this works as it should.

Approved with PullApprove

@mrunalp
Copy link
Contributor

mrunalp commented Mar 21, 2019

LGTM

Approved with PullApprove

@mrunalp mrunalp merged commit dd22a84 into opencontainers:master Mar 21, 2019
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Mar 28, 2019
full diff: opencontainers/runc@2b18fe1...v1.0.0-rc7

changes included:

- opencontainers/runc#2012 Need to setup labeling of kernel keyrings
- opencontainers/runc#2014 Add $RUNC_USE_SYSTEMD to run tests using systemd cgroup driver
- opencontainers/runc#2015 Use getenv not secure_getenv
  - fixes opencontainers/runc#2013 build fails with musl libc
- opencontainers/runc#2023 Fixes regression causing zombie runc:[1:CHILD] processes

Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Mar 28, 2019
full diff: opencontainers/runc@2b18fe1...v1.0.0-rc7

changes included:

- opencontainers/runc#2012 Need to setup labeling of kernel keyrings
- opencontainers/runc#2014 Add $RUNC_USE_SYSTEMD to run tests using systemd cgroup driver
- opencontainers/runc#2015 Use getenv not secure_getenv
  - fixes opencontainers/runc#2013 build fails with musl libc
- opencontainers/runc#2023 Fixes regression causing zombie runc:[1:CHILD] processes

Signed-off-by: Sebastiaan van Stijn <[email protected]>
(cherry picked from commit bc6ac08)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Mar 28, 2019
full diff: opencontainers/runc@2b18fe1...v1.0.0-rc7

changes included:

- opencontainers/runc#2012 Need to setup labeling of kernel keyrings
- opencontainers/runc#2014 Add $RUNC_USE_SYSTEMD to run tests using systemd cgroup driver
- opencontainers/runc#2015 Use getenv not secure_getenv
  - fixes opencontainers/runc#2013 build fails with musl libc
- opencontainers/runc#2023 Fixes regression causing zombie runc:[1:CHILD] processes

Signed-off-by: Sebastiaan van Stijn <[email protected]>
(cherry picked from commit bc6ac08)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants