diff mbox series

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

Message ID 20220715191622.2310436-1-mcgrof@kernel.org (mailing list archive)
State New, archived
Headers show
Series [v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op | expand

Commit Message

Luis Chamberlain July 15, 2022, 7:16 p.m. UTC
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.

[0] https://lkml.kernel.org/r/8adf55db-7bab-f59d-d612-ed906b948d19@schaufler-ca.com

Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd")
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
Changes on v2:

 - Added Fixes tag as requested by Paul Moore

 - Moved the security_uring_cmd() check after checking
   for req->file->f_op->uring_cmd as suggested by Paul Moore

 include/linux/lsm_hook_defs.h | 1 +
 include/linux/lsm_hooks.h     | 3 +++
 include/linux/security.h      | 5 +++++
 io_uring/uring_cmd.c          | 5 +++++
 security/security.c           | 4 ++++
 5 files changed, 18 insertions(+)

Comments

Jens Axboe July 15, 2022, 7:28 p.m. UTC | #1
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:

Acked-by: Jens Axboe <axboe@kernel.dk>
Paul Moore July 15, 2022, 7:52 p.m. UTC | #2
On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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:
>
> Acked-by: Jens Axboe <axboe@kernel.dk>

Thank you both.
Paul Moore July 16, 2022, 3:33 a.m. UTC | #3
On Fri, Jul 15, 2022 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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.
Casey Schaufler July 18, 2022, 5:12 p.m. UTC | #4
On 7/15/2022 8:33 PM, Paul Moore wrote:
> On Fri, Jul 15, 2022 at 3:52 PM Paul Moore <paul@paul-moore.com> wrote:
>> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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?

Thanks.
Paul Moore July 18, 2022, 9:52 p.m. UTC | #5
On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey@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@paul-moore.com> wrote:
> >> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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?

All I have at the moment is the audit-testsuite io_uring test (link
below) which is lacking a test for the io_uring CMD command.  I plan
on adding that, but I haven't finished the SELinux patch yet.

* https://github.com/linux-audit/audit-testsuite/tree/main/tests/io_uring

(Side note: there will be a SELinux io_uring test similar to the
audit-testsuite test, but that effort was delayed due to lack of
io_uring support in the Fedora policy for a while; it's working now,
but the SELinux/SCTP issues have been stealing my time lately.)
Kanchan Joshi July 19, 2022, 4:47 a.m. UTC | #6
On Mon, Jul 18, 2022 at 05:52:01PM -0400, Paul Moore wrote:
>On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey@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@paul-moore.com> wrote:
>> >> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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?

Earlier testing was done using fio. liburing tests need a formal review
in list. Tree is here -
https://github.com/ankit-sam/liburing/tree/uring-pt
It adds new "test/io_uring_passthrough.t", which can be run this way:

./test/io_uring_passthrough.t /dev/ng0n1

Requires nvme device (/dev/ng0n1). And admin-access as well, as this
is raw open. FWIW, each passthrough command (at nvme driver level) is
also guarded by admin-access.

Ankit (CCed) has the plans to post it (will keep you guys in loop) after
bit more testing with 5.20 branch.

>All I have at the moment is the audit-testsuite io_uring test (link
>below) which is lacking a test for the io_uring CMD command.  I plan
>on adding that, but I haven't finished the SELinux patch yet.
>
>* https://protect2.fireeye.com/v1/url?k=9cb2caea-fd39dfd9-9cb341a5-000babff9bb7-e1f9086bae09b852&q=1&e=b1985274-4644-447d-be8c-16f520cadbd9&u=https%3A%2F%2Fgithub.com%2Flinux-audit%2Faudit-testsuite%2Ftree%2Fmain%2Ftests%2Fio_uring
>
>(Side note: there will be a SELinux io_uring test similar to the
>audit-testsuite test, but that effort was delayed due to lack of
>io_uring support in the Fedora policy for a while; it's working now,
>but the SELinux/SCTP issues have been stealing my time lately.)
Ming Lei July 19, 2022, 1:54 p.m. UTC | #7
On Tue, Jul 19, 2022 at 10:17:17AM +0530, Kanchan Joshi wrote:
> On Mon, Jul 18, 2022 at 05:52:01PM -0400, Paul Moore wrote:
> > On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey@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@paul-moore.com> wrote:
> > > >> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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?
> 
> Earlier testing was done using fio. liburing tests need a formal review
> in list. Tree is here -
> https://github.com/ankit-sam/liburing/tree/uring-pt
> It adds new "test/io_uring_passthrough.t", which can be run this way:
> 
> ./test/io_uring_passthrough.t /dev/ng0n1
> 
> Requires nvme device (/dev/ng0n1). And admin-access as well, as this
> is raw open. FWIW, each passthrough command (at nvme driver level) is
> also guarded by admin-access.
> 
> Ankit (CCed) has the plans to post it (will keep you guys in loop) after
> bit more testing with 5.20 branch.

Another candidate is ublksrv[1] which doesn't require any device and
is pretty easy to setup. However, the kernel side driver(ublk_drv) isn't
merged to linus tree yet, but has been in for-5.20/block.

And io_uring command is sent to both /dev/ublk-control and /dev/ublkcN.

[1] https://github.com/ming1/ubdsrv.git


Thanks,
Ming
Paul Moore July 20, 2022, 3:06 p.m. UTC | #8
On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey@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@paul-moore.com> wrote:
> >> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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?
Jens Axboe July 20, 2022, 3:11 p.m. UTC | #9
On 7/20/22 9:06 AM, Paul Moore wrote:
> On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <casey@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@paul-moore.com> wrote:
>>>> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <axboe@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.
Luis Chamberlain Aug. 10, 2022, 6:14 p.m. UTC | #10
On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
> 
> Acked-by: Jens Axboe <axboe@kernel.dk>

Paul, Casey, Jens,

should this be picked up now that we're one week into the merge window?

  Luis
Paul Moore Aug. 10, 2022, 6:39 p.m. UTC | #11
On Wed, Aug 10, 2022 at 2:14 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
> >
> > Acked-by: Jens Axboe <axboe@kernel.dk>
>
> Paul, Casey, Jens,
>
> should this be picked up now that we're one week into the merge window?

Your timing is spot on!  I wrapped up a SELinux/SCTP issue by posting
the patches yesterday and started on the io_uring/CMD patches this
morning :)

Give me a few days to get this finished, tested, etc. and I'll post a
patchset with your main patch, the Smack patch from Casey, the SELinux
patch, and the /dev/null patch so we can all give it a quick sanity
check before I merge it into the LSM/stable branch and send it to
Linus.  Does that sound okay?
Luis Chamberlain Aug. 10, 2022, 6:52 p.m. UTC | #12
On Wed, Aug 10, 2022 at 02:39:54PM -0400, Paul Moore wrote:
> On Wed, Aug 10, 2022 at 2:14 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
> > >
> > > Acked-by: Jens Axboe <axboe@kernel.dk>
> >
> > Paul, Casey, Jens,
> >
> > should this be picked up now that we're one week into the merge window?
> 
> Your timing is spot on!  I wrapped up a SELinux/SCTP issue by posting
> the patches yesterday and started on the io_uring/CMD patches this
> morning :)
> 
> Give me a few days to get this finished, tested, etc. and I'll post a
> patchset with your main patch, the Smack patch from Casey, the SELinux
> patch, and the /dev/null patch so we can all give it a quick sanity
> check before I merge it into the LSM/stable branch and send it to
> Linus.  Does that sound okay?

Works with me! But just note I'll be away on vacation starting tomorrow
in the woods looking for Bigfoot with my dog, so I won't be around. And
I suspect Linus plans to release 6.0 on Sunday, if the phb-crystall-ball [0]
is still as accurate.

[0] http://deb.tandrin.de/phb-crystal-ball.htm

  Luis
Casey Schaufler Aug. 10, 2022, 7:26 p.m. UTC | #13
On 8/10/2022 11:52 AM, Luis Chamberlain wrote:
> On Wed, Aug 10, 2022 at 02:39:54PM -0400, Paul Moore wrote:
>> On Wed, Aug 10, 2022 at 2:14 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>>> On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
>>>>
>>>> Acked-by: Jens Axboe <axboe@kernel.dk>
>>> Paul, Casey, Jens,
>>>
>>> should this be picked up now that we're one week into the merge window?
>> Your timing is spot on!  I wrapped up a SELinux/SCTP issue by posting
>> the patches yesterday and started on the io_uring/CMD patches this
>> morning :)
>>
>> Give me a few days to get this finished, tested, etc. and I'll post a
>> patchset with your main patch, the Smack patch from Casey, the SELinux
>> patch, and the /dev/null patch so we can all give it a quick sanity
>> check before I merge it into the LSM/stable branch and send it to
>> Linus.  Does that sound okay?

It's taking a while to get a satisfactory test going for Smack,
but I should have something in a few days.

> Works with me! But just note I'll be away on vacation starting tomorrow
> in the woods looking for Bigfoot with my dog,

Bigfoot was sighted lounging on Chuckanut Rock a couple weeks ago.

>  so I won't be around. And
> I suspect Linus plans to release 6.0 on Sunday, if the phb-crystall-ball [0]
> is still as accurate.
>
> [0] http://deb.tandrin.de/phb-crystal-ball.htm
>
>   Luis
Paul Moore Aug. 10, 2022, 10:14 p.m. UTC | #14
On Wed, Aug 10, 2022 at 2:52 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> On Wed, Aug 10, 2022 at 02:39:54PM -0400, Paul Moore wrote:
> > On Wed, Aug 10, 2022 at 2:14 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > >
> > > On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
> > > >
> > > > Acked-by: Jens Axboe <axboe@kernel.dk>
> > >
> > > Paul, Casey, Jens,
> > >
> > > should this be picked up now that we're one week into the merge window?
> >
> > Your timing is spot on!  I wrapped up a SELinux/SCTP issue by posting
> > the patches yesterday and started on the io_uring/CMD patches this
> > morning :)
> >
> > Give me a few days to get this finished, tested, etc. and I'll post a
> > patchset with your main patch, the Smack patch from Casey, the SELinux
> > patch, and the /dev/null patch so we can all give it a quick sanity
> > check before I merge it into the LSM/stable branch and send it to
> > Linus.  Does that sound okay?
>
> Works with me! But just note I'll be away on vacation starting tomorrow
> in the woods looking for Bigfoot with my dog, so I won't be around. And
> I suspect Linus plans to release 6.0 on Sunday, if the phb-crystall-ball [0]
> is still as accurate.

No worries, hopefully we'll have something working its way towards
Linus by the time you return.  Enjoy your time away.
Paul Moore Aug. 10, 2022, 10:15 p.m. UTC | #15
On Wed, Aug 10, 2022 at 3:26 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 8/10/2022 11:52 AM, Luis Chamberlain wrote:
> > On Wed, Aug 10, 2022 at 02:39:54PM -0400, Paul Moore wrote:
> >> On Wed, Aug 10, 2022 at 2:14 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >>> On Fri, Jul 15, 2022 at 01:28:35PM -0600, Jens Axboe 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:
> >>>>
> >>>> Acked-by: Jens Axboe <axboe@kernel.dk>
> >>> Paul, Casey, Jens,
> >>>
> >>> should this be picked up now that we're one week into the merge window?
> >> Your timing is spot on!  I wrapped up a SELinux/SCTP issue by posting
> >> the patches yesterday and started on the io_uring/CMD patches this
> >> morning :)
> >>
> >> Give me a few days to get this finished, tested, etc. and I'll post a
> >> patchset with your main patch, the Smack patch from Casey, the SELinux
> >> patch, and the /dev/null patch so we can all give it a quick sanity
> >> check before I merge it into the LSM/stable branch and send it to
> >> Linus.  Does that sound okay?
>
> It's taking a while to get a satisfactory test going for Smack,
> but I should have something in a few days.

Thanks Casey.  When I get a test working for SELinux I'll be sure to
send it your way just in case.
diff mbox series

Patch

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index eafa1d2489fd..4e94755098f1 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -406,4 +406,5 @@  LSM_HOOK(int, 0, perf_event_write, struct perf_event *event)
 #ifdef CONFIG_IO_URING
 LSM_HOOK(int, 0, uring_override_creds, const struct cred *new)
 LSM_HOOK(int, 0, uring_sqpoll, void)
+LSM_HOOK(int, 0, uring_cmd, struct io_uring_cmd *ioucmd)
 #endif /* CONFIG_IO_URING */
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 91c8146649f5..b681cfce6190 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1575,6 +1575,9 @@ 
  *      Check whether the current task is allowed to spawn a io_uring polling
  *      thread (IORING_SETUP_SQPOLL).
  *
+ * @uring_cmd:
+ *      Check whether the file_operations uring_cmd is allowed to run.
+ *
  */
 union security_list_options {
 	#define LSM_HOOK(RET, DEFAULT, NAME, ...) RET (*NAME)(__VA_ARGS__);
diff --git a/include/linux/security.h b/include/linux/security.h
index 4d0baf30266e..421856919b1e 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2053,6 +2053,7 @@  static inline int security_perf_event_write(struct perf_event *event)
 #ifdef CONFIG_SECURITY
 extern int security_uring_override_creds(const struct cred *new);
 extern int security_uring_sqpoll(void);
+extern int security_uring_cmd(struct io_uring_cmd *ioucmd);
 #else
 static inline int security_uring_override_creds(const struct cred *new)
 {
@@ -2062,6 +2063,10 @@  static inline int security_uring_sqpoll(void)
 {
 	return 0;
 }
+static inline int security_uring_cmd(struct io_uring_cmd *ioucmd)
+{
+	return 0;
+}
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_IO_URING */
 
diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
index 0a421ed51e7e..bf76f487d525 100644
--- a/io_uring/uring_cmd.c
+++ b/io_uring/uring_cmd.c
@@ -3,6 +3,7 @@ 
 #include <linux/errno.h>
 #include <linux/file.h>
 #include <linux/io_uring.h>
+#include <linux/security.h>
 
 #include <uapi/linux/io_uring.h>
 
@@ -85,6 +86,10 @@  int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
 	if (!req->file->f_op->uring_cmd)
 		return -EOPNOTSUPP;
 
+	ret = security_uring_cmd(ioucmd);
+	if (ret)
+		return ret;
+
 	if (ctx->flags & IORING_SETUP_SQE128)
 		issue_flags |= IO_URING_F_SQE128;
 	if (ctx->flags & IORING_SETUP_CQE32)
diff --git a/security/security.c b/security/security.c
index f85afb02ea1c..ad7d7229bd72 100644
--- a/security/security.c
+++ b/security/security.c
@@ -2655,4 +2655,8 @@  int security_uring_sqpoll(void)
 {
 	return call_int_hook(uring_sqpoll, 0);
 }
+int security_uring_cmd(struct io_uring_cmd *ioucmd)
+{
+	return call_int_hook(uring_cmd, 0, ioucmd);
+}
 #endif /* CONFIG_IO_URING */