On 28/01/2020 23:19, Jens Axboe wrote: > On 1/28/20 1:16 PM, Pavel Begunkov wrote: >> On 28/01/2020 22:42, Jens Axboe wrote: >>> On 1/28/20 11:04 AM, Jens Axboe wrote: >>>> On 1/28/20 10:19 AM, Jens Axboe wrote: >>>>> On 1/28/20 9:19 AM, Jens Axboe wrote: >>>>>> On 1/28/20 9:17 AM, Stefan Metzmacher wrote: >>>>> OK, so here are two patches for testing: >>>>> >>>>> https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs-creds >>>>> >>>>> #1 adds support for registering the personality of the invoking task, >>>>> and #2 adds support for IORING_OP_USE_CREDS. Right now it's limited to >>>>> just having one link, it doesn't support a chain of them. >>>>> >>>>> I'll try and write a test case for this just to see if it actually works, >>>>> so far it's totally untested. >>>>> >>>>> Adding Pavel to the CC. >>>> >>>> Minor tweak to ensuring we do the right thing for async offload as well, >>>> and it tests fine for me. Test case is: >>>> >>>> - Run as root >>>> - Register personality for root >>>> - create root only file >>>> - check we can IORING_OP_OPENAT the file >>>> - switch to user id test >>>> - check we cannot IORING_OP_OPENAT the file >>>> - check that we can open the file with IORING_OP_USE_CREDS linked >>> >>> I didn't like it becoming a bit too complicated, both in terms of >>> implementation and use. And the fact that we'd have to jump through >>> hoops to make this work for a full chain. >>> >>> So I punted and just added sqe->personality and IOSQE_PERSONALITY. >>> This makes it way easier to use. Same branch: >>> >>> https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs-creds >>> >>> I'd feel much better with this variant for 5.6. >>> >> >> To be honest, sounds pretty dangerous. Especially since somebody started talking >> about stealing fds from a process, it could lead to a nasty loophole somehow. >> E.g. root registers its credentials, passes io_uring it to non-privileged >> children, and then some process steals the uring fd (though, it would need >> priviledged mode for code-injection or else). Could we Cc here someone really >> keen on security? > > Link? If you can steal fds, then surely you've already lost any sense of https://lwn.net/Articles/808997/ But I didn't looked up it yet. > security in the first place? Besides, if root registered the ring, the root > credentials are already IN the ring. I don't see how this adds any extra > holes. Isn't it what you fixed in ("don't use static creds/mm assignments") ? I'm not sure what capability (and whether any) it would need, but better to think such cases through. Just saying, I would prefer to ask a person with extensive security experience, unlike me. >> Stefan, could you please explain, how this 5 syscalls pattern from the first >> email came in the first place? Just want to understand the case. > > I think if you go back a bit in the archive, Stefan has a fuller explanation > of how samba does the credentials dance. Missed it, I'll take a look, thanks -- Pavel Begunkov
Attachment:
signature.asc
Description: OpenPGP digital signature
