public inbox for [email protected]
 help / color / mirror / Atom feed
From: Casey Schaufler <[email protected]>
To: Luis Chamberlain <[email protected]>
Cc: [email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected]
Subject: Re: [PATCH] lsm,io_uring: add LSM hooks to for the new uring_cmd file op
Date: Thu, 14 Jul 2022 18:25:03 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <YtC6wT4CYq0an/[email protected]>

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

  reply	other threads:[~2022-07-15  1:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  0:05 [PATCH] lsm,io_uring: add LSM hooks to for the new uring_cmd file op Luis Chamberlain
2022-07-14  0:38 ` Casey Schaufler
2022-07-15  0:54   ` Luis Chamberlain
2022-07-15  1:25     ` Casey Schaufler [this message]
2022-07-14  3:00 ` Paul Moore
2022-07-15  1:00   ` Luis Chamberlain
2022-07-15 18:46     ` Paul Moore
2022-07-15 19:02       ` Luis Chamberlain
2022-07-15 19:51         ` Paul Moore
2022-07-15 19:07       ` Jens Axboe
2022-07-15 19:50         ` Paul Moore
2022-07-15 20:00           ` Jens Axboe
2022-07-15 21:16             ` Casey Schaufler
2022-07-15 21:32               ` Jens Axboe
2022-07-15 21:37             ` Luis Chamberlain
2022-07-15 21:47               ` Jens Axboe
2022-07-15 20:50       ` Casey Schaufler
2022-07-15 23:03         ` Casey Schaufler
2022-07-15 23:05           ` Jens Axboe
2022-07-15 23:14             ` Casey Schaufler
2022-07-15 23:18               ` Jens Axboe
2022-07-15 23:31                 ` Casey Schaufler
2022-07-15 23:34                   ` Jens Axboe
2022-07-16  3:20       ` Kanchan Joshi
2022-07-18 14:55         ` 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=be4ec1e4-89c8-9a1c-bb2e-6f158312270e@schaufler-ca.com \
    [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