-
Couldn't load subscription status.
- Fork 881
stage1: restrict access to procfs and sysfs paths #2683
Conversation
tests/rkt_mountns_test.go
Outdated
| // /proc and /sys is correctly restricted: | ||
| // https://github.com/coreos/rkt/issues/2484 | ||
| func TestProcFSRestrictions(t *testing.T) { | ||
|
|
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.
superfluous empty line
stage1/init/common/pod.go
Outdated
| path string | ||
| inaccessible bool | ||
| readonly bool | ||
| }{ |
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.
Since inaccessible and readonly are mutually exclusive, and the for loop handle them separately, restrictedPaths could be split in two separate arrays of strings.
43385e4 to
4e2ce2a
Compare
|
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.
4e2ce2a to
66bb5c5
Compare
|
@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 |
|
The test needs to be fixed somehow, but otherwise LGTM if green. |
|
FYI the test for the exit code is not executed on the kvm flavor: |
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 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. |
I thought there was a discussion but I don't find it. I only found this comment: #2198 (comment)
Ok. LGTM. But it does not fully fix #2484. Do you plan to open follow-up issues or to keep #2484 open? |
|
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. |
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