From: Pavel Begunkov <[email protected]>
To: Paul Moore <[email protected]>
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected],
Kumar Kartikeya Dwivedi <[email protected]>,
Jens Axboe <[email protected]>,
Alexander Viro <[email protected]>
Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring
Date: Tue, 25 May 2021 09:27:28 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHC9VhSJuddB+6GPS1+mgcuKahrR3UZA=1iO8obFzfRE7_E0gA@mail.gmail.com>
On 5/24/21 8:59 PM, Paul Moore wrote:
> On Sun, May 23, 2021 at 4:26 PM Pavel Begunkov <[email protected]> wrote:
>> On 5/22/21 3:36 AM, Paul Moore wrote:
>>> On Fri, May 21, 2021 at 8:22 PM Pavel Begunkov <[email protected]> wrote:
>>>> On 5/21/21 10:49 PM, Paul Moore wrote:
>> [...]
>>>>>
>>>>> + if (req->opcode < IORING_OP_LAST)
>>>>
>>>> always true at this point
>>>
>>> I placed the opcode check before the audit call because the switch
>>> statement below which handles the operation dispatching has a 'ret =
>>> -EINVAL' for the default case, implying that there are some paths
>>> where an invalid opcode could be passed into the function. Obviously
>>> if that is not the case and you can guarantee that req->opcode will
>>> always be valid we can easily drop the check prior to the audit call.
>>
>> It is always true at this point, would be completely broken
>> otherwise
>
> Understood, I was just pointing out an oddity in the code. I just
> dropped the checks from my local tree, you'll see it in the next draft
> of the patchset.
>
>>>> So, it adds two if's with memory loads (i.e. current->audit_context)
>>>> per request in one of the hottest functions here... No way, nack
>>>>
>>>> Maybe, if it's dynamically compiled into like kprobes if it's
>>>> _really_ used.
>>>
>>> I'm open to suggestions on how to tweak the io_uring/audit
>>> integration, if you don't like what I've proposed in this patchset,
>>> lets try to come up with a solution that is more palatable. If you
>>> were going to add audit support for these io_uring operations, how
>>> would you propose we do it? Not being able to properly audit io_uring
>>> operations is going to be a significant issue for a chunk of users, if
>>> it isn't already, we need to work to find a solution to this problem.
>>
>> Who knows. First of all, seems CONFIG_AUDIT is enabled by default
>> for many popular distributions, so I assume that is not compiled out.
>>
>> What are use cases for audit? Always running I guess?
>
> Audit has been around for quite some time now, and it's goal is to
> provide a mechanism for logging "security relevant" information in
> such a way that it meets the needs of various security certification
> efforts. Traditional Linux event logging, e.g. syslog and the like,
> does not meet these requirements and changing them would likely affect
> the usability for those who are not required to be compliant with
> these security certifications. The Linux audit subsystem allows Linux
> to be used in places it couldn't be used otherwise (or rather makes it
> a *lot* easier).
>
> That said, audit is not for everyone, and we have build time and
> runtime options to help make life easier. Beyond simply disabling
> audit at compile time a number of Linux distributions effectively
> shortcut audit at runtime by adding a "never" rule to the audit
> filter, for example:
>
> % auditctl -a task,never
>
>> Putting aside compatibility problems, it sounds that with the amount of overhead
>> it adds there is no much profit in using io_uring in the first place.
>> Is that so?
>
> Well, if audit alone erased all of the io_uring advantages we should
> just rip io_uring out of the kernel and people can just disable audit
> instead ;)
Hah, if we add a simple idle "feature" like
for (i=0;i<1000000;i+) {;}
and it would destroy all the performance, let's throw useless
Linux kernel then!
If seriously, it's more of an open question to me, how much overhead
it adds if enabled (with typical filters/options/etc).
Btw, do you really need two hooks -- before and right after
execution?
> I believe there are people who would like to use io_uring and are also
> required to use a kernel with audit, either due to the need to run a
> distribution kernel or the need to capture security information in the
> audit stream. I'm hoping that we can find a solution for these users;
> if we don't we are asking this group to choose either io_uring or
> audit, and that is something I would like to avoid.
--
Pavel Begunkov
next prev parent reply other threads:[~2021-05-25 8:27 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 21:49 [RFC PATCH 0/9] Add LSM access controls and auditing to io_uring Paul Moore
2021-05-21 21:49 ` [RFC PATCH 1/9] audit: prepare audit_context for use in calling contexts beyond syscalls Paul Moore
2021-05-21 21:49 ` [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring Paul Moore
2021-05-22 0:22 ` Pavel Begunkov
2021-05-22 2:36 ` Paul Moore
2021-05-23 20:26 ` Pavel Begunkov
2021-05-24 19:59 ` Paul Moore
2021-05-25 8:27 ` Pavel Begunkov [this message]
2021-05-25 14:53 ` Paul Moore
2021-05-26 1:11 ` Jens Axboe
2021-05-26 2:04 ` Paul Moore
2021-05-26 10:19 ` Pavel Begunkov
2021-05-26 14:38 ` Paul Moore
2021-05-26 15:11 ` Steve Grubb
2021-05-26 15:17 ` Stefan Metzmacher
2021-05-26 15:49 ` Richard Guy Briggs
2021-05-26 17:22 ` Jens Axboe
2021-05-27 17:27 ` Richard Guy Briggs
2021-05-26 15:49 ` Victor Stewart
2021-05-26 16:38 ` Casey Schaufler
2021-05-26 17:15 ` Jens Axboe
2021-05-26 17:31 ` Jens Axboe
2021-05-26 17:54 ` Jens Axboe
2021-05-26 18:01 ` Jens Axboe
2021-05-26 18:44 ` Paul Moore
2021-05-26 18:57 ` Pavel Begunkov
2021-05-26 19:10 ` Paul Moore
2021-05-26 19:44 ` Jens Axboe
2021-05-26 20:19 ` Paul Moore
2021-05-28 16:02 ` Paul Moore
2021-06-02 8:26 ` Pavel Begunkov
2021-06-02 15:46 ` Richard Guy Briggs
2021-06-03 10:39 ` Pavel Begunkov
2021-06-02 19:46 ` Paul Moore
2021-06-03 10:51 ` Pavel Begunkov
2021-06-03 15:54 ` Casey Schaufler
2021-06-03 15:54 ` Jens Axboe
2021-06-04 5:04 ` Paul Moore
2021-05-26 18:38 ` Paul Moore
2021-06-02 17:29 ` [RFC PATCH 2/9] audit, io_uring, io-wq: " Richard Guy Briggs
2021-06-02 20:46 ` Paul Moore
2021-08-25 1:21 ` Richard Guy Briggs
2021-08-25 19:41 ` Paul Moore
2021-05-21 21:50 ` [RFC PATCH 3/9] audit: dev/test patch to force io_uring auditing Paul Moore
2021-05-21 21:50 ` [RFC PATCH 4/9] audit: add filtering for io_uring records Paul Moore
2021-05-28 22:35 ` Richard Guy Briggs
2021-05-30 15:26 ` Paul Moore
2021-05-31 13:44 ` Richard Guy Briggs
2021-06-02 1:40 ` Paul Moore
2021-06-02 15:37 ` Richard Guy Briggs
2021-06-02 17:20 ` Paul Moore
2021-05-31 13:44 ` [PATCH 1/2] audit: add filtering for io_uring records, addendum Richard Guy Briggs
2021-05-31 16:08 ` kernel test robot
2021-05-31 17:38 ` kernel test robot
2021-06-07 23:15 ` Paul Moore
2021-06-08 12:55 ` Richard Guy Briggs
2021-06-09 2:45 ` Paul Moore
2021-05-31 13:44 ` [PATCH 2/2] audit: block PERM fields being used with io_uring filtering Richard Guy Briggs
2021-05-21 21:50 ` [RFC PATCH 5/9] fs: add anon_inode_getfile_secure() similar to anon_inode_getfd_secure() Paul Moore
2021-05-21 21:50 ` [RFC PATCH 6/9] io_uring: convert io_uring to the secure anon inode interface Paul Moore
2021-05-21 21:50 ` [RFC PATCH 7/9] lsm,io_uring: add LSM hooks to io_uring Paul Moore
2021-05-26 14:48 ` Stefan Metzmacher
2021-05-26 20:45 ` Paul Moore
2021-05-21 21:50 ` [RFC PATCH 8/9] selinux: add support for the io_uring access controls Paul Moore
2021-05-21 21:50 ` [RFC PATCH 9/9] Smack: Brutalist io_uring support with debug Paul Moore
2021-05-22 0:53 ` [RFC PATCH 0/9] Add LSM access controls and auditing to io_uring Tetsuo Handa
2021-05-22 2:06 ` Paul Moore
2021-05-26 15:00 ` Jeff Moyer
2021-05-26 18:49 ` Paul Moore
2021-05-26 19:07 ` Jeff Moyer
2021-05-26 19:10 ` 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 \
[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