Message ID | 20240427112451.1609471-1-stsp2@yandex.ru (mailing list archive) |
---|---|
Headers | show |
Series | implement OA2_CRED_INHERIT flag for openat2() | expand |
On 2024-04-27, Stas Sergeev <stsp2@yandex.ru> wrote: > This patch-set implements the OA2_CRED_INHERIT flag for openat2() syscall. > It is needed to perform an open operation with the creds that were in > effect when the dir_fd was opened, if the dir was opened with O_CRED_ALLOW > flag. This allows the process to pre-open some dirs and switch eUID > (and other UIDs/GIDs) to the less-privileged user, while still retaining > the possibility to open/create files within the pre-opened directory set. > > The sand-boxing is security-oriented: symlinks leading outside of a > sand-box are rejected. /proc magic links are rejected. fds opened with > O_CRED_ALLOW are always closed on exec() and cannot be passed via unix > socket. > The more detailed description (including security considerations) > is available in the log messages of individual patches. (I meant to reply last week but I couldn't get my mail server to send mail...) It seems to me that this can already be implemented using MOUNT_ATTR_IDMAP, without creating a new form of credential overriding within the filesystem (and with such a deceptively simple implementation...) If you are a privileged process which plans to change users, you can create a detached tree with a user mapping that gives that user access to only that tree. This is far more effective at restricting possible attacks because id-mapped mounts don't override credentials during VFS operations (meaning that if you miss something, you have a big problem), instead they only affect uid-related operations within the filesystem for that mount. Since this implementation does no inherit CAP_DAC_OVERRIDE, being able to rewrite uid/gids is all you need. 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. Since O_CRED_INHERIT uses override_creds, it doesn't care about whether something about the O_CRED_ALLOW directory changed afterwards. Yes, you can "just fix this" by adding a RESOLVE_NO_XDEV requirement too, but given that there have been 2-3 security issues with this design found already, it makes me feel really uneasy. Using id-mapped mounts avoids this issue because the new mount will not have the id-mapping applied and thus there is no security issue.
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? > 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.
On 2024-05-07, stsp <stsp2@yandex.ru> 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.)
07.05.2024 14:58, Aleksa Sarai пишет: > On 2024-05-07, stsp <stsp2@yandex.ru> 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. Then its likely not a replacement for my proposal, as I really don't need that on tmpfs. Perhaps right now I can use the helper process and an rpc as a replacement. This is much more work and is slower, but more or less can approximate my original design decision quite precisely. Another disadvantage of an rpc approach is that the fds I get from the helper process, can not be trusted, as in this case kernel doesn't guarantee the fd actually refers to the resource I requested. I've seen a few OSes where rpc is checked by a trusted entity to avoid such problem. >>> 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. Oh, isn't this a problem by itself? Yes, in this case my patch needs to avoid RESOLVE_NO_XDEV, but I find this a harsh restriction. Maybe the bind mount was done before a priv drop? Then it is fully legitimate. Anyway, I don't know if I should work on it or not, as there seem to be no indication of a possible acceptance.