Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Feb 24, 2020. It is now read-only.

Conversation

@lucab
Copy link
Member

@lucab lucab commented May 24, 2016

Many procfs and sysfs endpoints are currently not namespace-aware
and can be used by malicious pods to manipulate host state
and escape the sandboxing.
This commit introduces an initial mitigation, by marking those
paths as read-only or inaccessible to containers.

(Partially) Fixes #2484

// /proc and /sys is correctly restricted:
// https://github.com/coreos/rkt/issues/2484
func TestProcFSRestrictions(t *testing.T) {

Copy link
Member

Choose a reason for hiding this comment

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

superfluous empty line

path string
inaccessible bool
readonly bool
}{
Copy link
Member

Choose a reason for hiding this comment

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

Since inaccessible and readonly are mutually exclusive, and the for loop handle them separately, restrictedPaths could be split in two separate arrays of strings.

@lucab lucab force-pushed the to-upstream/procfs-sysfs-restrictions branch 3 times, most recently from 43385e4 to 4e2ce2a Compare May 24, 2016 16:40
@lucab
Copy link
Member Author

lucab commented May 25, 2016

Rebased according to comments. Travis failure is still due to a git-validation hiccup, but the semaphoreci one seems to be due to kvm returning wrong return value. Is this a known issue and should I not rely on that?

Many procfs and sysfs endpoints are currently not namespace-aware
and can be used by malicious pods to manipulate host state
and escape the sandboxing.
This commit introduces an initial mitigation, by marking those
paths as read-only or inaccessible to containers.
@lucab lucab force-pushed the to-upstream/procfs-sysfs-restrictions branch from 4e2ce2a to 66bb5c5 Compare May 25, 2016 09:07
@alban
Copy link
Member

alban commented May 25, 2016

@lucab yes, with kvm, rkt does not return the exit code from the application. This feature was added not so long ago in systemd-nspawn. Not sure what to do for the test: patching /inspect --write-file to always return the exit code 0 on error as well? inspect is just for testing, so we can make it have the semantic we want for the tests.

@alban
Copy link
Member

alban commented May 25, 2016

The test needs to be fixed somehow, but otherwise LGTM if green.

@alban
Copy link
Member

alban commented May 25, 2016

FYI the test for the exit code is not executed on the kvm flavor:
https://github.com/coreos/rkt/blob/master/tests/rkt_exit_test.go#L15

@lucab
Copy link
Member Author

lucab commented May 25, 2016

yes, with kvm, rkt does not return the exit code from the application. This feature was added not so long ago in systemd-nspawn.

Is there any technical impediment for this or is it just a missing feature for the moment? (If the latter, I didn't find any previous bug report)

Not sure what to do for the test: patching /inspect --write-file to always return the exit code 0 on error as well? inspect is just for testing, so we can make it have the semantic we want for the tests.

I prefer to have it bubble-up return values on errors.

I moved this test out of kvm for the moment. It shouldn't be a major concern, as the hypervisor is anyway already built without support for most of those procfs/sysfs options. PTAL.

@alban
Copy link
Member

alban commented May 25, 2016

Is there any technical impediment for this or is it just a missing feature for the moment? (If the latter, I didn't find any previous bug report)

I thought there was a discussion but I don't find it. I only found this comment: #2198 (comment)

I prefer to have it bubble-up return values on errors.

I moved this test out of kvm for the moment. It shouldn't be a major concern, as the hypervisor is anyway already built without support for most of those procfs/sysfs options. PTAL.

Ok. LGTM. But it does not fully fix #2484. Do you plan to open follow-up issues or to keep #2484 open?

@lucab
Copy link
Member Author

lucab commented May 25, 2016

I'd keep #2484 open, it already contains quite a bit of sorted info. I left a TODO in code, I'll just reference it from there.

@alban alban merged commit 1ffd4f9 into rkt:master May 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants