Re: IORING_REGISTER_CREDS[_UPDATE]() and credfd_create()?

[Jens Axboe <axboe@kernel.dk>]

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
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.

> 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.

-- 
Jens Axboe