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

Older kernels do not support keyring labeling #51

Merged
merged 1 commit into from
Apr 23, 2019

Conversation

rhatdan
Copy link
Collaborator

@rhatdan rhatdan commented Apr 4, 2019

Ignore setting the kernel keyring label if the
/proc/self/attr/keycreate file does not exists.

runc attempts to set this file on older kernels and is blowing up.

Signed-off-by: Daniel J Walsh dwalsh@redhat.com

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 4, 2019

@cyphar @vrothberg @mrunalp PTAL

@cyphar
Copy link
Member

cyphar commented Apr 4, 2019

This is similar to what I suggested in #49, though I do wonder why not just do it like this:

diff --git a/go-selinux/selinux_linux.go b/go-selinux/selinux_linux.go
index 51fa8de68a33..45e47f5eda00 100644
--- a/go-selinux/selinux_linux.go
+++ b/go-selinux/selinux_linux.go
@@ -341,6 +341,10 @@ func writeCon(fpath string, val string) error {
 
        out, err := os.OpenFile(fpath, os.O_WRONLY, 0)
        if err != nil {
+               // Non-existent /proc files indicate a vintage kernel.
+               if os.IsNotExist(err) {
+                       err = nil
+               }
                return err
        }
        defer out.Close()

So any new writeCon users in the future will also handle old kernels.

In any case, LGTM.

@lifubang
Copy link
Member

lifubang commented Apr 4, 2019

@cyphar @rhatdan I think this PR can't fix my issue.
I spent some time dig into it, and with @rhatdan 's help, find the real reason.

My English is not very well, please see code in #52 .

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 4, 2019

@cyphar I think the problem I have with this is it would be easy to mistake a success versus a typo in the code.
Which would not be caught until far later. We know of a specific case of keycreate, so we handle it.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 4, 2019

@lifubang Could you show me the failure you are seeing with permission denied? I would always want that feedback.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 4, 2019

@lifubang I updated this PR to handle your issue.

Ignore setting the kernel keyring label if the
/proc/self/attr/keycreate file does not exists.

runc attempts to set this file on older kernels and is blowing up.

If a system has a /proc/self/attr/keyring and the caller attempts to set
the label to "" and SELinux is disabled, ignore the error.

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@lifubang
Copy link
Member

lifubang commented Apr 5, 2019

@lifubang I updated this PR to handle your issue.

No, this can't fix my issue. Please see #52 .
If have any suggestions, please input in #52 . I will debug it. Thanks.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 5, 2019

What error does this patch miss? Your patch misses Permission Denied.

@lifubang
Copy link
Member

lifubang commented Apr 5, 2019

What error does this patch miss? Your patch misses Permission Denied.

I think we don't need it any more.

if os.IsNotExist(err) {
return nil
}
if label == "" && os.IsPermission(err) && !GetEnabled() {
Copy link
Member

Choose a reason for hiding this comment

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

Once we really have no permission to keycreate?
So I don't think we should use this err check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This will check if someone executes runc on a machine with /proc/self/attr/keycreate, attempted to set "", got permission denied, and SELinux was disabled, so we ignore the error.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, not SELinux disabled, but SELinux enabled.

@lifubang
Copy link
Member

lifubang commented Apr 5, 2019

What error does this patch miss?

I can't explain it in one sentence because of my English's level.
Please see #52 (comment) to get full understand.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 5, 2019

@lifubang Lets stick to my PR. Rather then switching back and forth.
This misses the case where the user is allowed to read keycreate but is not allowed to write to keycreate, and is writing "" with a disabled SELinux system.

@lifubang
Copy link
Member

lifubang commented Apr 5, 2019

I think I need to debug it to ensure it is really right, so I will work on in my PR #52 .
If I don't explain clearly, you can see my code.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 19, 2019

@cpuguy83 Does this fix the issue you are seeing. I will merge and open a vendor for runc if it does. I am not in favor of the other patch.

Copy link
Contributor

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

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

Looks like it would. I will give it a try later today.
Thanks!

@cpuguy83
Copy link
Contributor

Ok, so the issue is GetEnabled() is is true when runc is compiled with selinux support.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 20, 2019

@cpuguy83 Is this on an SELinux system? Is SELinux enabled?

@@ -1 +1 @@
1.3.0-dev
1.2.2
Copy link
Member

Choose a reason for hiding this comment

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

Did you mean to commit this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes I am only bumping the minor number, Since this is only a bugfix.

Copy link
Member

Choose a reason for hiding this comment

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

Sure but usually releases in OCI go through a voting process and so on. Bit odd to include it in an ordinary PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have not been following any such procedure on the SELinux package. I guess I could, but have not in the past. Bottom line, I would like to get this PR Verified as fixing the issue and then vendored into runc, so we can fix it there.

Copy link
Member

@cyphar cyphar Apr 22, 2019

Choose a reason for hiding this comment

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

Sure, do whatever works for you.

The release procedures for all opencontainers projects (except I guess selinux) have all used the voting system we use for spec releases, but it's pretty obvious that's not a great model for non-spec projects. I'm hoping to correct this after we get 1.0.0 out.

@cpuguy83
Copy link
Contributor

@rhatdan

Is this on an SELinux system? Is SELinux enabled?

Yes and yes.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 21, 2019

@cpuguy83 And did a patched version of runc with this patch fix the issue. I take it this is using an older RHEL/Centos kernel that did not support keycreate labels?

@cpuguy83
Copy link
Contributor

cpuguy83 commented Apr 22, 2019

@rhatdan I'm using CentOS on Azure (kernel 3.10.0-862.11.6.el7.x86_64).
Unpatched this works fine if I set --selinux-enabled=true on docker, but otherwise (--selinux-enabled=false, the default) I get EPERM even with this patch.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 22, 2019

Are you seeing AVCs?
Does it work with setenforce 0.

@cpuguy83
Copy link
Contributor

Denial is:

type=PROCTITLE msg=audit(1555611120.741:866): proctitle=2F7573722F62696E2F72756E6300696E6974
type=SYSCALL msg=audit(1555611120.741:866): arch=c000003e syscall=1 success=no exit=-13 a0=8 a1=557a6f0ab780 a2=0 a3=0 items=0 ppid=10782 pid=10790 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="runc:[2:INIT]" exe="/" subj=system_u:system_r:container_runtime_t:s0 key=(null)
type=AVC msg=audit(1555611120.741:866): avc:  denied  { create } for  pid=10790 comm="runc:[2:INIT]" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=key

With setenforce 0 there is no issue.

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 22, 2019

This is a container-selinux issue. The latest container-selinux-2.91 and greater allows this AVC. So give this a LGTM and we can move on.
Of course I would like to know what SELinux label is being put into the process label of a container when SELinux is disabled in docker. It should be "", but this patch would catch that. So I am thinking you are sending some other label. Can you grab the runtime spec json file and see what the process label is?

@mrunalp @runcom PTAL at this PR, I believe it is correct and @cpuguy83 is experiencing an different issue, that is fixed in container-selinux package.

@mrunalp
Copy link
Contributor

mrunalp commented Apr 23, 2019

LGTM

Approved with PullApprove

@mrunalp mrunalp merged commit bed8545 into opencontainers:master Apr 23, 2019
@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 23, 2019

@cpuguy83 I just fixed another issue in container-selinux to allow spc_t to write unlabeled_t files.
We are packaging up the fix in container-selinux-2.100

@cyphar
Copy link
Member

cyphar commented Apr 24, 2019

Can we get a tagged release so we can bump runc? 💚

@rhatdan
Copy link
Collaborator Author

rhatdan commented Apr 24, 2019

opencontainers/runc#2043

thaJeztah added a commit to thaJeztah/docker that referenced this pull request Apr 26, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Apr 26, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Apr 28, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e5aab17)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/containerd that referenced this pull request Apr 28, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e5aab17)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 05c3be6)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
docker-jenkins pushed a commit to docker-archive/docker-ce that referenced this pull request May 10, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 0d453115fe0b1b19c08c614b6029c4edf92a0f0a
Component: engine
thaJeztah added a commit to thaJeztah/docker that referenced this pull request May 13, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0d45311)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
docker-jenkins pushed a commit to docker-archive/docker-ce that referenced this pull request May 14, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0d453115fe0b1b19c08c614b6029c4edf92a0f0a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: e7a837120de1f4f2d45c673e758bd444441a0c8f
Component: engine
kiku-jw pushed a commit to kiku-jw/moby that referenced this pull request May 16, 2019
full diff: opencontainers/selinux@v1.2.1...v1.2.2

- opencontainers/selinux#51 Older kernels do not support keyring labeling

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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.

5 participants