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
runtime: readonly volume should be bind mounted readonly on the host #1062
Conversation
|
/test |
|
/test |
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.
Thanks @bergwolf.
Any way you could create a new test explicitly to check for this behaviour?
|
@awprice PTAL |
To make sure readonly volumes are mounted readonly both inside the guest and on the host. Depends-on: github.com/kata-containers/kata-containers#1062 Fixes: kata-containers#3022 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
To make sure readonly volumes are mounted readonly both inside the guest and on the host. Depends-on: github.com/kata-containers/kata-containers#1062 Fixes: kata-containers#3022 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
|
@jodh-intel sure, pls see kata-containers/tests#3023 |
To make sure readonly volumes are mounted readonly both inside the guest and on the host. Depends-on: github.com/kata-containers/kata-containers#1062 Fixes: kata-containers#3022 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
|
Thanks for raising this so quickly @bergwolf! It looks good to me, but I haven't had a chance to test this as I'm still on 1.11.3 |
|
@awprice ah, I see. I just backported the PR here kata-containers/runtime#3042 |
|
@bergwolf Thanks! I'll test out the 1.x code tomorrow |
| if err := bindMount(c.ctx, m.Source, mountDest, m.ReadOnly, "private"); err != nil { | ||
| return "", false, err | ||
| } | ||
| // Save HostPath mount value into the mount list of the container. | ||
| c.mounts[idx].HostPath = mountDest | ||
| // bindmount remount event is not propagated to mount subtrees, so we have to remount the shared dir mountpoint directly. | ||
| if m.ReadOnly { | ||
| mountDest = filepath.Join(hostSharedDir, filename) |
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.
@bergwolf I suppose this is a newly added commit. Will this allow the guest to perform an unmount in case of a container escape, the vulnerability CVE-2020-2024 that we addressed before?
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.
nop, this is host mount. guest cannot change it and only sees the readonly directory.
|
I've tested the 1.x code in my environment and it fixes the issue. |
To make sure readonly volumes are mounted readonly both inside the guest and on the host. Depends-on: github.com/kata-containers/kata-containers#1062 Fixes: kata-containers#3022 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
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.
othanks @bergwolf - one nit
|
/test |
|
/test |
So that we get protected at the VM boundary not just the guest kernel. Signed-off-by: Peng Tao <bergwolf@hyper.sh>
bindmount remount events are not propagated through mount subtrees, so we have to remount the shared dir mountpoint directly. E.g., ``` mkdir -p source dest foo source/foo mount -o bind --make-shared source dest mount -o bind foo source/foo echo bind mount rw mount | grep foo echo remount ro mount -o remount,bind,ro source/foo mount | grep foo ``` would result in: ``` bind mount rw /dev/xvda1 on /home/ubuntu/source/foo type ext4 (rw,relatime,discard,data=ordered) /dev/xvda1 on /home/ubuntu/dest/foo type ext4 (rw,relatime,discard,data=ordered) remount ro /dev/xvda1 on /home/ubuntu/source/foo type ext4 (ro,relatime,discard,data=ordered) /dev/xvda1 on /home/ubuntu/dest/foo type ext4 (rw,relatime,discard,data=ordered) ``` The reason is that bind mount creats new mount structs and attaches them to different mount subtrees. However, MS_REMOUNT only looks for existing mount structs to modify and does not try to propagate the change to mount structs in other subtrees. Fixes: kata-containers#1061 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
|
/test |
|
There is a regression introduced by #1037 and it is causing crio + k8s configmap to fail a lot on multiple platforms in different PRs. I've added an extra commit to revert the offending commit: ref: #1080 |
|
/test-vfio |
|
vfio test is failing at Should we just run The same is failing on other unrelated PRs as well, e.g., http://jenkins.katacontainers.io/job/kata-containers-2.0-vfio-PR/184/console |
|
@bergwolf yeah I'm on that kata-containers/tests#3026 |
|
/test |
This reverts commit 87848e8 as it is breaking the k8s configMap test. Fixex: kata-containers#1080 Signed-off-by: Peng Tao <bergwolf@hyper.sh>
|
/test |
1 similar comment
|
/test |
|
/test-vfio |
So that even if the guest is compromised, we still ensure that readonly volumes cannot be modified.