From: Christian Brauner <[email protected]>
To: Paul Moore <[email protected]>
Cc: Jens Axboe <[email protected]>,
[email protected], [email protected],
[email protected], [email protected]
Subject: Re: IORING_OP_FIXED_FD_INSTALL and audit/LSM interactions
Date: Mon, 22 Jan 2024 16:15:22 +0100 [thread overview]
Message-ID: <20240122-desaster-weiten-967544d0d5a1@brauner> (raw)
In-Reply-To: <CAHC9VhRBkW4bH0K_-PeQ5HA=5yMHSimFboiQgG9iDcwYVZcSFQ@mail.gmail.com>
On Fri, Jan 19, 2024 at 11:33:37AM -0500, Paul Moore wrote:
> Hello all,
>
> I just noticed the recent addition of IORING_OP_FIXED_FD_INSTALL and I
> see that it is currently written to skip the io_uring auditing.
> Assuming I'm understanding the patch correctly, and I'll admit that
> I've only looked at it for a short time today, my gut feeling is that
> we want to audit the FIXED_FD_INSTALL opcode as it could make a
> previously io_uring-only fd generally accessible to userspace.
>
> I'm also trying to determine how worried we should be about
> io_install_fixed_fd() potentially happening with the current task's
> credentials overridden by the io_uring's personality. Given that this
> io_uring operation inserts a fd into the current process, I believe
> that we should be checking to see if the current task's credentials,
> and not the io_uring's credentials/personality, are allowed to receive
> the fd in receive_fd()/security_file_receive(). I don't see an
> obvious way to filter/block credential overrides on a per-opcode
> basis, but if we don't want to add a mask for io_kiocb::flags in
> io_issue_defs (or something similar), perhaps we can forcibly mask out
> REQ_F_CREDS in io_install_fixed_fd_prep()? I'm very interested to
> hear what others think about this.
Right, completely forgot about the creds support in io_uring. Just
disallow this together with FIXED_FD_INSTALL. That's also the gist of
the rest of this thread iiuc.
prev parent reply other threads:[~2024-01-22 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 16:33 IORING_OP_FIXED_FD_INSTALL and audit/LSM interactions Paul Moore
2024-01-19 17:02 ` Jens Axboe
2024-01-19 17:20 ` Paul Moore
2024-01-19 17:41 ` Jens Axboe
2024-01-19 17:54 ` Paul Moore
2024-01-19 18:00 ` Jens Axboe
2024-01-22 15:15 ` Christian Brauner [this message]
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=20240122-desaster-weiten-967544d0d5a1@brauner \
[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