Secure and user friendly mounts for unprivileged

[techtonik (anatoly techtonik)]

Did anything change in recent LXD versions to allow unprivileged containers to write access user directories in secure and user friendly way? By that I mean:

1. No write for everybody mode on a host machine
2. No read only files created by container on a host
3. No broken permissions if a host is rebooted
4. No mounting of /, $HOME and .ssh unless explicitly asked

While I can script p.4, the first 3 points deem an unsolvable problem for me.

[tomp (Thomas Parrott)]

An issue that was preventing read only mounts with shiftfs enabled (which shifts the uid/gid of the mount into the container) has been recently fixed, so that may be of interest.

See:

Mount home directory read only permission denied

Hi, I am trying to mount my home directory to the /home/ubuntu directory in my LXD container. I want it to be read only i.e. I want to read the data inside the container but not write or modify it. But when I do try to even access a file for example with cat command, I get permission denied error. This is how I am doing it right now: lxc init ubuntu classifier lxc config device add classifier homedir disk source=$HOME path=/home/ubuntu lxc start classifier Then I go inside the container to…

[techtonik (anatoly techtonik)]

Thanks. I could make the volume writable after enabling shiftfs with LXD and using shift=true for adding disk devices:

lxc config device add $NAME $NAME-shared disk source=$PWD \
  path=/root/$NAME shift=true

But I am still not sure it is secure after reading this thread on setuid:

Trying out `shiftfs`

Yeah, if setuid is possible on a path that’s visible to an unprivileged user on the host, root in the container could say copy /bin/sh to that path, chown 0:0 and chmod u+s it, making it setuid root for anyone on the host who’s allowed to run it.

I am not sure that getting into details of what setuid is and how it works is user friendly approach to security. Maybe there is no concern in this case? Is there a code I can run on guest/host to check if my mount is exploitable to this setuid attack?

[tomp (Thomas Parrott)]

Are you wanting a readonly mount? I’m not really clear what you are asking for.

[techtonik (anatoly techtonik)]

I want rw mount without security implications of setuid attack (whatever it is).

[tomp (Thomas Parrott)]

@stgraber @brauner is this possible?

[stgraber (Stéphane Graber)]

If the filesystem on the host is mounted with nosuid, then this would avoid anyone running setuid binaries from it. However all it would take is one system reconfiguration missing the nosuid to be back in trouble.

I don’t know if the new version of this mechanism (idmapped mounts) would allow for putting an irreversible restriction on the container side mount so that no suid permissions may be written through it, I doubt that such a mechanism is currently part of it, but maybe it can be added to the kernel without too much difficulity.

[techtonik (anatoly techtonik)]

The default filesystem for user’s $HOME on Ubuntu is mounted without nosuid. I assume that makes shift=true unsafe to use on user systems for running random scripts from GitHub in isolation.

Another problem with shift=true is that condition 2. No read only files created by container on a host is not fulfilled. The files created from guest system are owned by root:root on host. If I would do git pull from the guest, that would create ro files that then will give errors on subsequent git operations from the host.