Messages in this thread | | | Date | Thu, 25 Apr 2024 13:12:12 +0300 | Subject | Re: [PATCH v4 0/2] implement OA2_INHERIT_CRED flag for openat2() | From | stsp <> |
| |
25.04.2024 12:54, Christian Brauner пишет: > I'm not sure what you don't understand or why you need further > clarification. Your patch allows any opener using your new flag to steal > the uid/gid/whatever from the original opener.
No, absolutely impossible (see below).
> It was even worse in the > first version where the whole struct cred of the original opener was > used. It's obviously a glaring security hole that's opened up by this.
Well, it was the second version actually (first one only had fsuid/fsgid), but no, its the same thing either way. The creds are overridden for a diration of an openat2() syscall. It doesn't matter what uid/gid are there, because they are not used during openat2(), and are reverted back at the end. The only reason I decided to get back to fsuid/fsgid, were the capabilities, which I don't want to be raised during openat2().
> Let alone that the justification "It's useful for some lightweight > sandboxing" is absolutely not sufficient to justify substantial shifts > in the permission model. > > The NAK stands.
But I am sure you still don't understand what exactly the patch does, so why not to ask instead of asserting? You say uid/gid can be stolen, but no, it can't: the creds are reverted. Only fsuid/fsgid (and caps in v2 of the patch) actually affect openat2(), but nothing is "leaked" after openat2() finished.
That said, Viro already pointed to the actual problem, and the patch-testing bot did the same. So I have a valid complains already, and you don't have to add the invalid ones to them. :)
| |