Messages in this thread | | | Date | Sun, 28 Apr 2024 20:39:16 +0300 | Subject | Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() | From | stsp <> |
| |
28.04.2024 19:41, Andy Lutomirski пишет: >> On Apr 26, 2024, at 6:39 AM, 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. >> > Then two different things could be done: > > 1. The subtree could be used unmounted or via /proc magic links. This > would be for programs that are aware of this interface. > > 2. The subtree could be mounted, and accessed through the mount would > use the captured creds. Doesn't this have the same problem that was pointed to me? Namely (explaining my impl first), that if someone puts the cred fd to an unaware process's fd table, such process can't fully drop its privs. He may not want to access these dirs, but once its hacked, the hacker will access these dirs with the creds came from an outside. My solution was to close such fds on exec and disallowing SCM_RIGHTS passage. SCM_RIGHTS can be allowed in the future, but the receiver will need to use some new flag to indicate that he is willing to get such an fd. Passage via exec() can probably never be allowed however.
If I understand your model correctly, you put a magic sub-tree to the fs scope of some unaware process. He may not want to access it, but once hacked, the hacker will access it with the creds from an outside. And, unlike in my impl, in yours there is probably no way to prevent that?
In short: my impl confines the hassle within the single process. It can be extended, and then the receiver will need to explicitly allow adding such fds to his fd table. But your idea seems to inherently require 2 processes, and there is probably no way for the second process to say "ok, I allow such sub-tree in my fs scope". And even if he could, in my impl he can just close the cred fd, while in yours it seems to persist.
Sorry if I misunderstood your idea.
| |