[Feature request] Native support for mounting proc with hidepid

LXD
#1

Hi folks,

I’m running 4.16 in the lab, and the 4.0 LTS in production, and I can’t find a reasonable way to do this on either of them. It seems you used to be able to just remount /proc with hidepid={1,2} but at least with the stock Ubuntu (minimal or otherwise) images this doesn’t work (proc is mounted read-only, so remount doesn’t work, nor does putting it in /etc/fstab).

The only ways we’ve found to make it work on modern LXD is:

  • security.nesting=True - this is unpalatable for security reasons, the trade-off of this in exchange for hidepid isn’t a good one. I also don’t 100% understand the mechanism by which it allows it, I’m guessing it’s something to do with changing the way mounts are handled so that an LXD can run in an LXD container?
  • Adding a bunch of lines to raw.lxc to clobber the mount for /proc when LXC spawns it with the mount options we want.

The latter works, but in production we tend to sit on a stable version of LXD for a long time, and then where possible like to maintain the ability to transfer containers between the two versions while we transition everything to the new version. In the past, raw.lxc has caused us grief here, when a configuration key is deprecated and no longer supported in a newer version, the container move fails for non-obvious reasons.

So it’d be nice - but definitely not urgent/required - to have a configuration key for enabling hidepid on a supported container (obviously it would be unsupported in VMs, I’d think?), where LXD handles it for us?

Thoughts?

1 Like
#2

I played around a bit with this and it looks like apparmor can’t handle hidepid=1/hidepid=2 so we can’t allow put a rule in place which would allow it.

security.nesting=true works because it effectively causes a blanket mount, rule allowing all mounts which then happen to match it.

I played around with things a bit and apparmor just seems to not see the flag at all and if specifically allowed, the policy fails to load…

You can reproduce that on your side by looking at the dmesg output which would normally show hidepid=1 in the flags triggering the denial but it won’t be shown.

#3

Thanks, so does this mean that any such feature would depend on changes in apparmor first?

#4

Yeah, looks like apparmor doesn’t properly handle hidepid, so there’s no way for us to allow it in our policies without making our mount policy effectively wide open.

We’d also need a way to detect an apparmor parser with the needed support so that we’d only put in those allow rules if the parser will support it (as otherwise containers would fail to start).