On 2024-05-07, stsp <stsp2@xxxxxxxxx> wrote: > 07.05.2024 10:50, Aleksa Sarai пишет: > > If you are a privileged process which plans to change users, > > Not privileged at all. But I think what you say is still possible with > userns? It is possible to configure MOUNT_ATTR_IDMAP in a user namespace but there are some restrictions that I suspect will make this complicated. If you try to do something with a regular filesystem you'll probably run into issues because you won't have CAP_SYS_ADMIN in the super block's userns. But you could probably do it with tmpfs. > > A new attack I just thought of while writing this mail is that because > > there is no RESOLVE_NO_XDEV requirement, it should be possible for the > > process to get an arbitrary write primitive by creating a new > > userns+mountns and then bind-mounting / underneath the directory. > Doesn't this need a write perm to a > directory? In his case this is not a threat, > because you are not supposed to have a > write perm to that dir. OA2_CRED_INHERIT > is the only way to write. No, bind-mounts don't require write permission. As long as you can resolve the target path you can bind-mount on top of it, so if there's a subdirectory you can bind-mount / underneath (and if there is only a file you can bind-mount any file you want to access/overwrite instead). There are restrictions on mounting through /proc/self/fd/... but they don't apply here (all files opened by a process doing setns/unshare have their vfsmounts updated to be from the new mount namespace, meaning you can do mounts through them with /proc/self/fd/... without issue.) -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
