UID mapping for disk sharing and UID process

[Olivier]

Hello,

I’ve set up UID/GID remapping in order to share a disk with the host and this works wonderfully. However, I noticed that my processes are also UID-remapped.

For instance, with the following enabled for my container:

  security.idmap.isolated: true
  raw.idmap: |-
    uid 1000 1000
    gid 1000 1000

I will get the following processes on my host:

UID	Process	Host/Container
0	init	host
1000	htop	host
200001	init	container
200033	polkitd	container
1000	vim	container

My concern is about the last process. In my understanding, the UID remapping was only for disk access, but it seems the full process is UID-remapped?
Does it mean that if someone breaks out of the container they will have access to the host as the 1000 user? Does not this defeat the goal of UID-shifting?

I’m a bit confused if I understand well the consequences of remapping an UID. Can you confirm if my hypothesis above are correct?

In case they are correct, what are my solutions to share disks with the host and still keep and the UID-shift intact?
I see shiftfs, but is it a viable solution? I didn’t see much documentation about it and this looks relatively new.
Is there any other solution (other than some UID/ACL hacking on the host) ?

[toby63]

Hi,

I recommend shiftfs.

@Olivier

I see shiftfs , but is it a viable solution? I didn’t see much documentation about it and this looks relatively new.

It is in use and activated by default in Ubuntu, it is considered stable.
See for example: Trying out `shiftfs` - #58 by brauner

“Documentation” is in the Forum (for now):

Share folders and volumes between host and containers

Note: In recent kernels (>5.12) a new approach called “idmapped mounts” is directly included in the Linux kernel. It acts as a replacement/sucessor of shiftfs and uses all the below mentioned commands as well. It only supports ext4, xfs, vfat and btrfs (>5.15) for the underlying filesystems of LXD for now, but ZFS and cephfs are planned to be included as well. If you use unsupported filesystems or older kernels, stick with shiftfs for now. Usecases: General Advantages: faster startup o…

Regarding Security of shiftfs:

@Olivier

Does it mean that if someone breaks out of the container they will have access to the host as the 1000 user? Does not this defeat the goal of UID-shifting?

Note: This explanation is for shiftfs!
Not really, It’s more complicated than that.
Users from the container will not have host access.
But a root or sudo user inside a container can set the uid of a file on the host and then a user on the host could use it to get root access.
But there are ways to prevent it.
See:
Trying out shiftfs - comment 48
Trying out shiftfs - comment 54

[Olivier]

I’ve set up my container with a shared disk and shiftfs and it’s working as I wanted it. I still have to create a new partition to forbid nosuid,nodev on mount.

Thank you for the documentation and especially for the github to add the shiftfs module to the kernel. You have my star.