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

[proposal]: option to not mask or set read-only paths in /proc #36597

Closed
jessfraz opened this Issue Mar 14, 2018 · 18 comments

Comments

Projects
None yet
6 participants
@jessfraz
Contributor

jessfraz commented Mar 14, 2018

I would like to create a feature that is an option to disable the masked paths and read-only paths for /proc.

The purpose is for nesting user namespaced rootless containers inside a docker container without setting --privileged

It would solve the following bug:
opencontainers/runc#1658 (comment)

Reproducible here (the dockerfile lives here: https://github.com/jessfraz/dockerfiles/tree/master/runc-rootless):

$ docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined r.j3ss.co/runc-rootless
container_linux.go:297: starting container process caused "process_linux.go:402: container init caused \"rootfs_linux.go:58: mounting \\\"proc\\\" to rootfs \\\"/home/user/rootfs\\\" at \\\"/proc\\\" caused \\\"operation not permitted\\\"\""

If I turn off the masked paths and readonly paths then this will work and I can fulfill my use case and sleep at night. I am more than happy to write it in a way that you choose and file a PR.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Mar 14, 2018

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Mar 14, 2018

oh, let me add @n4ss as well 😄

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 14, 2018

what about --i-know-what-i-am-doing-its-okay-im-sorry-to-the-proc-gods :P

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Mar 14, 2018

--self-destruct-mode or --acidburn-if-you-use-this 😂

@n4ss

This comment has been minimized.

n4ss commented Mar 14, 2018

ah yeah this is something that I also wanted :p

I did add that a while back as part of the host.devices=admin entitlement here:

ociProfile.OCI.Mounts = removeReadOnlyFlagMounts(ociProfile.OCI.Mounts)
ociProfile.OCI.Linux.MaskedPaths = []string{}

(https://github.com/moby/libentitlement/blob/master/defaults/host_ents.go#L137-139)

I'd like to see that happen in the meantime (at least as an experimental flag before the entitlements get finalized & approved).

@n4ss

This comment has been minimized.

n4ss commented Mar 14, 2018

note to myself: I only removed the ro flag from the mounts but forgot to empty the ReadOnlyPaths path set...

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 14, 2018

@n4ss

This comment has been minimized.

n4ss commented Mar 14, 2018

@jessfraz we're already looking to find a way to deprecate --privileged and adjust the granularity of the security configuration through the "docker entitlements" + security profiles for images. Disabling the access restrictions on host resources is part of these.

We have a working POC on docker run and docker build:

This will most likely be the thing that you want (and eventually will get approved + non-experimental) with the following command:

$ docker run --entitlements="host.devices=admin" jessfraz/iknowwhatimdoing:seriously

I hope to get that out asap (waiting for more community input among other things), but in the meantime yeah I agree that a flag doing that would be great. The experimental aspect allows to remove the flag when the entitlements are available (and have it earlier available I guess).

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 14, 2018

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 14, 2018

@n4ss

This comment has been minimized.

n4ss commented Mar 14, 2018

Is there an anticipated release planned for that

No, unfortunately

@n4ss

This comment has been minimized.

n4ss commented Mar 14, 2018

I think alternatively I might just add this to the cri implementations
because that’s really only where I need it

Makes sense but I still think that this (no masked paths / no RO paths) is needed on the Docker CLI.

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 14, 2018

@squillace

This comment has been minimized.

squillace commented Mar 15, 2018

--hoist-on-my-petard?

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 15, 2018

I just want to summarize so it’s clear and make sure I understand correctly what you all have in mind and my goals.

(I know you all and you know me so I’m not going to beat around the bush or do some silly political BS lol. You know that’s definitely not my thing.)

I need a way to get this functionality from k8s. That would require it being in a stable docker release so I can pull it up. I’m definitely not going to shaft you all with supporting some experimental flag if no one is going to support experimental docker in their production clusters (and they won’t) so that’s kinda pointless.

You all seem to have entitlements on your roadmap. I don’t see a future where I can get this into a stable release before that happens right? (That’s a genuine question).

It seems like my easiest option is to go straight for the CRI implementations and add it there. And just let docker catch up in k8s after entitlements are added.

OR

What if I promised to be in held accountable for deleting the flag after you all do entitlements, and redoing the support for the option in k8s to then support the entitlements implementation instead... so basically it wouldn’t be work on your plate but rather on mine. It could even be a hidden flag lol. Or not even a flag just an API field. I really just need the API field.

Real talk, I really just need to get this into k8s somehow so I can move on with my life and do the next thing on my list :) so I think an experimental flag would be a waste of both our time, ya know. I’m trying to optimize on the least amount of pain for everyone involved.

Also as far as naming I was thinking of making my proposal to k8s “RawProc” idk kinda sounds normal. We shall see :)

@n4ss

This comment has been minimized.

n4ss commented Mar 16, 2018

(I know you all and you know me so I’m not going to beat around the bush or do some silly political BS lol. You know that’s definitely not my thing.)

Sorry, I'm probably missing context here. Is it related to this particular issue or the LSM/visibility/permission access granularity on the FS?

What if I promised to be in held accountable for deleting the flag after you all do entitlements, and redoing the support for the option in k8s to then support the entitlements implementation instead... so basically it wouldn’t be work on your plate but rather on mine. It could even be a hidden flag lol. Or not even a flag just an API field. I really just need the API field.

We'd have to discuss it but if we plan to deprecate the privileged flag at some point, it might make sense to also deprecate the "subsets" that we'd add in the meantime (including this one) before the entitlements get rolled out. If so, this would keep the process as painful as it's already meant to be.

It's a rather simple flag to implement additionally, although I'm not sure that we want only --rawproc but potentially --raw-access=[system-path-to-whitelist] (people might want to whitelist subsets of the sysfs too for example) and is probably useful to people out there on the docker run CLI so I'm really fine with it.

bank-account -= $0.02

cc @vieux as well

@m-barthelemy

This comment has been minimized.

m-barthelemy commented Jun 3, 2018

Hi, is this one going to be merged?

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Jun 4, 2018

the pr is open here: #36644

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment