Message ID | 20220715191622.2310436-1-mcgrof@kernel.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op | expand |
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>
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.
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.
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.
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.)
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.)
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
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?
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.
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
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?
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
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
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.
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 --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 */
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(+)