public inbox for [email protected]
 help / color / mirror / Atom feed
From: Kanchan Joshi <[email protected]>
To: Paul Moore <[email protected]>
Cc: Casey Schaufler <[email protected]>,
	Jens Axboe <[email protected]>,
	Luis Chamberlain <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected]
Subject: Re: [PATCH v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op
Date: Tue, 19 Jul 2022 10:17:17 +0530	[thread overview]
Message-ID: <20220719044717.GA22571@test-zns> (raw)
In-Reply-To: <CAHC9VhRzjLFg9B4wL7GvW3WY-qM4BoqqcpyS0gW8MUbQ9BD2mg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]

On Mon, Jul 18, 2022 at 05:52:01PM -0400, Paul Moore wrote:
>On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <[email protected]> wrote:
>> On 7/15/2022 8:33 PM, Paul Moore wrote:
>> > On Fri, Jul 15, 2022 at 3:52 PM Paul Moore <[email protected]> wrote:
>> >> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <[email protected]> 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.)

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2022-07-19  4:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 19:16 [PATCH v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op Luis Chamberlain
2022-07-15 19:28 ` Jens Axboe
2022-07-15 19:52   ` Paul Moore
2022-07-16  3:33     ` Paul Moore
2022-07-18 17:12       ` Casey Schaufler
2022-07-18 21:52         ` Paul Moore
2022-07-19  4:47           ` Kanchan Joshi [this message]
2022-07-19 13:54             ` Ming Lei
2022-07-20 15:06         ` Paul Moore
2022-07-20 15:11           ` Jens Axboe
2022-08-10 18:14   ` Luis Chamberlain
2022-08-10 18:39     ` Paul Moore
2022-08-10 18:52       ` Luis Chamberlain
2022-08-10 19:26         ` Casey Schaufler
2022-08-10 22:15           ` Paul Moore
2022-08-10 22:14         ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220719044717.GA22571@test-zns \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox