Fwd: incus: How to use unprivileged UID/GID

[Narcis Garcia]

-------- Missatge reenviat --------
Assumpte: incus: How to use unprivileged UID/GID
Data: Wed, 8 May 2024 20:35:49 +0200
De: Narcis Garcia
A: LXC users SPM <lxc-...@lists.linuxcontainers.org>

Hello, I'm testing with incus LTS on/from Debianbookworm-backports
(using DIR storage pool):

sudo apt install incus
sudo incus admin init
sudo incus launch images:debian/12 MyContainerName
sudo ls -l
/var/lib/incus/storage-pools/local/containers/MyContainerName/rootfs

I see there all files with same UID/GID range as host.
How to make incus to create and map subuid/subgid when creating a
container? I want to apply "unprivileged" concept to filesystem same as
the use of lxc.idmap on LXC.

Thank you.

--

Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should remove and omit any @, dot and mailto combinations against
automated addresses collectors.

[Narcis Garcia]

Now I've tried this to create container from an already "unprivileged" user:

$ sudo apt install incus
$ sudo incus admin init
$ incus launch images:debian/12 MyContainerName
Error: You don't have the needed permissions to talk to the incus daemon
(socket path: /var/lib/incus/unix.socket)
$ sudo usermod --append --groups incus-admin $USER
$ newgrp incus-admin
$ incus launch images:debian/12 MyContainerName
$ sudo ls -l
/var/lib/incus/storage-pools/local/containers/MyContainerName/rootfs

And the result is the same using DIR storage pool:

I see there all files with same UID/GID range as host.

This means when guest is doing actions as guest's "root" is using same
root UID&GID as host as reflected in filesystem.
Anyway, any "incus-admin" group member has privileged permissions to
manage containers, and I don't want to give this status to guest user.

How to make incus creates and maps subuid/subgid when creating a
container? I want to apply full "unprivileged" concept and I want to see
this on filesystem same as the use of lxc.idmap by LXC.

An example of a production scenario with LXC unprivileged containers:
$ stat -c %u:%g /
0:0
$ cd /var/lib/lxc.u/lxc
$ sudo stat -c %u:%g MyContainerName1/rootfs
4032160:4032160
$ sudo cat MyContainerName1/config | grep -e idmap
lxc.idmap = u 0 4032160 65536
lxc.idmap = g 0 4032160 65536
$ sudo stat -c %u:%g MyContainerName2/rootfs
4818592:4818592
$ sudo cat MyContainerName2/config | grep -e idmap
lxc.idmap = u 0 4818592 65536
lxc.idmap = g 0 4818592 65536

This is what I'm looking for, because I'm planning to migrate from pure
LXC to Incus.


El 3/6/24 a les 14:04, Narcis Garcia ha escrit:

[Serge E. Hallyn]

Start the container and get a shell, then do cat /proc/self/uid_map.

I think you'll find that the does have uid mapping, and the filesystems
(cat /proc/self/mount_info) are id_mapped. Now, I'm not the biggest fan
of this as it allows the user to create root owned files on the host,
though hidden behind a directory which unpriv users can't access.

> --
> You received this message because you are subscribed to the Google Groups "lxc-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lxc-users+...@lists.linuxcontainers.org.
> To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/e639d1c1-bd6d-4657-90a1-f6fecfe72209%40actiu.net.

[Narcis Garcia]

Hi Serge, I understand you suggest to check mapping from guest environment.
I want to see mapping from host, and being applied overall on host PIDs
UID/GID and on host inodes UID/GID.
I don't want any "unprivileged" guest can create files with host's UID 0
or run processes with host's UID 0 (or any other matching with host own
users, eg. 1, 33, 1000, 1001).

With LXC, I adduser an unprivileged account, and run:

$ sudo -iu UnprivilegedUser -- lxc-create -n MyContainerName -B dir -t
download -d debian -a amd64 -r bookworm

This takes lxc.idmap from
/home/lxc/.config/$UnprivilegedUser/default.conf ; for example:
lxc.idmap = u 0 4949664 65536
lxc.idmap = g 0 4949664 65536

And creates a rootfs with owners starting from uid/gid 4949664.
Host's UID 4949664 is guest's UID 0, and this means for me that any
guest file (and guest PID) is really unprivileged at host scope.
Clear.
Simple.
Not only this but multiple unprivileged containers I create them with
different UID/GID range, to be all unprivileged between them.

Is this supported by Incus? Some documentation to manage this behaviour?

Thank you.


El 3/6/24 a les 21:14, Serge E. Hallyn ha escrit:

[Serge E. Hallyn]

On Tue, Jun 04, 2024 at 09:34:52AM +0200, Narcis Garcia wrote:
> Hi Serge, I understand you suggest to check mapping from guest environment.
> I want to see mapping from host, and being applied overall on host PIDs
> UID/GID and on host inodes UID/GID.

I understand.

> I don't want any "unprivileged" guest can create files with host's UID 0 or
> run processes with host's UID 0 (or any other matching with host own users,
> eg. 1, 33, 1000, 1001).

In this case, the container can create files with host uid 0, but cannot
create processes with host uid 0. To take advantage of this, the container
admin would have to collude with an unprivileged user on the real host.
That unprivileged user should be unable to reach the host mounted container
rfs as /var/lib/incus/storage-pools/default/containers/CONTAINER is d--x------

I'm not entirely comfortable with that so we have discussed other steps to
take, but this is the case right now.

> With LXC, I adduser an unprivileged account, and run:
>
> $ sudo -iu UnprivilegedUser -- lxc-create -n MyContainerName -B dir -t
> download -d debian -a amd64 -r bookworm
>
> This takes lxc.idmap from /home/lxc/.config/$UnprivilegedUser/default.conf ;
> for example:
> lxc.idmap = u 0 4949664 65536
> lxc.idmap = g 0 4949664 65536
>
> And creates a rootfs with owners starting from uid/gid 4949664.
> Host's UID 4949664 is guest's UID 0, and this means for me that any guest
> file (and guest PID) is really unprivileged at host scope.

Yes I'm familiar with how lxc does it :)

> Clear.
> Simple.
> Not only this but multiple unprivileged containers I create them with
> different UID/GID range, to be all unprivileged between them.
>
> Is this supported by Incus? Some documentation to manage this behaviour?

No, it is not currently supported by Incus. We would definitely not want
to do it in all cases, so then the tradeoff would be added complexity.
There may be other ways to prevent the host mounted version from being
usable in the initial user namespace, but nothing concrete has been
implemented yet.

> To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/a8550b47-f859-41dd-b5f9-2961aac3f58e%40actiu.net.

[Narcis Garcia]

I submitted a feature request to not forgetting my wish:
https://github.com/lxc/incus/issues/923

Thank you for explaining situation and for the project.


El 5/6/24 a les 14:34, Serge E. Hallyn ha escrit:

--
Narcis Garcia