On 7/14/2022 5:54 PM, Luis Chamberlain wrote:
> On Wed, Jul 13, 2022 at 05:38:42PM -0700, Casey Schaufler wrote:
>> On 7/13/2022 5:05 PM, Luis Chamberlain wrote:
>>> io-uring cmd support was added through ee692a21e9bf ("fs,io_uring:
>>> add infrastructure for uring-cmd"), this extended the struct
>>> file_operations to allow a new command which each subsystem can use
>>> to enable command passthrough. Add an LSM specific for the command
>>> passthrough which enables LSMs to inspect the command details.
>>>
>>> This was discussed long ago without no clear pointer for something
>>> conclusive, so this enables LSMs to at least reject this new file
>>> operation.
>> tl;dr - Yuck. Again.
>>
>> You're passing the complexity of uring-cmd directly into each
>> and every security module. SELinux, AppArmor, Smack, BPF and
>> every other LSM now needs to know the gory details of everything
>> that might be in any arbitrary subsystem so that it can make a
>> wild guess about what to do. And I thought ioctl was hard to deal
>> with.
> Yes... I cannot agree anymore.
>
>> Look at what Paul Moore did for the existing io_uring code.
>> Carry that forward into your passthrough implementation.
> Which one in particular? I didn't see any glaring obvious answers.
Neither did I! I'm still playing catch-up on the initial io_uring
implementation. Smack's "Brutalist" support for io_uring isn't
especially satisfactory, and adding arbitrary sub-system defined
command behavior on top of what's already pretty mysterious
isn't going to make it any easier.
>
>> No, I don't think that waving security away because we haven't
>> proposed a fix for your flawed design is acceptable. Sure, we
>> can help.
> Hey if the answer was obvious it would have been implemented.
And it still needs to be implemented, even if it isn't obvious.
In the security world we don't get to say "Sure, the performance
sucks, but the optimization folks will take care of that later."
Throwing in a nebulous security hook and counting on the LSMs to
make rainbows out of it isn't going to fly either.
>
> Luis
