[PATCH v2] lsm, io_uring: add LSM hooks for the new uring_cmd file op

[Jens Axboe]

On 7/20/22 9:06 AM, Paul Moore wrote:
> On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 7/15/2022 8:33 PM, Paul Moore wrote:
>>> On Fri, Jul 15, 2022 at 3:52 PM Paul Moore <paul at paul-moore.com> wrote:
>>>> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe at kernel.dk> wrote:
>>>>> On 7/15/22 1:16 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.
>>>>> From an io_uring perspective, this looks fine to me. It may be easier if
>>>>> I take this through my tree due to the moving of the files, or the
>>>>> security side can do it but it'd have to then wait for merge window (and
>>>>> post io_uring branch merge) to do so. Just let me know. If done outside
>>>>> of my tree, feel free to add:
>>> I forgot to add this earlier ... let's see how the timing goes, I
>>> don't expect the LSM/Smack/SELinux bits to be ready and tested before
>>> the merge window opens so I'm guessing this will not be an issue in
>>> practice, but thanks for the heads-up.
>>
>> I have a patch that may or may not be appropriate. I ran the
>> liburing tests without (additional) failures, but it looks like
>> there isn't anything there testing uring_cmd. Do you have a
>> test tucked away somewhere I can use?
> 
> I just had a thought, would the io_uring folks be opposed if I
> submitted a patch to add a file_operations:uring_cmd for the null
> character device?  A simple uring_cmd noop seems to be in keeping with
> the null device, and it would make testing the io_uring CMD
> functionality much easier as it would not rely on a specific device.
> 
> I think something like this would be in keeping with the null driver:
> 
>   static int uring_cmd_null(struct io_uring_cmd *ioucmd, unsigned int
> issue_flags)
>   {
>     return 0;
>   }
> 
> Thoughts?

I think that's a good idea. We're adding an nvme based test for
liburing, but that's to be able to test the whole passthrough part, not
just uring_cmd in particular.

Adding a dummy one to null/zero makes sense for test purposes.

-- 
Jens Axboe