On Thu, Mar 10, 2022 at 07:43:04PM -0700, Jens Axboe wrote:
> On 3/10/22 6:51 PM, Luis Chamberlain wrote:
> > On Tue, Mar 08, 2022 at 08:50:51PM +0530, Kanchan Joshi wrote:
> >> From: Jens Axboe <axboe@xxxxxxxxx>
> >>
> >> This is a file private kind of request. io_uring doesn't know what's
> >> in this command type, it's for the file_operations->async_cmd()
> >> handler to deal with.
> >>
> >> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
> >> Signed-off-by: Kanchan Joshi <joshi.k@xxxxxxxxxxx>
> >> ---
> >
> > <-- snip -->
> >
> >> +static int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
> >> +{
> >> + struct file *file = req->file;
> >> + int ret;
> >> + struct io_uring_cmd *ioucmd = &req->uring_cmd;
> >> +
> >> + ioucmd->flags |= issue_flags;
> >> + ret = file->f_op->async_cmd(ioucmd);
> >
> > I think we're going to have to add a security_file_async_cmd() check
> > before this call here. Because otherwise we're enabling to, for
> > example, bypass security_file_ioctl() for example using the new
> > iouring-cmd interface.
> >
> > Or is this already thought out with the existing security_uring_*() stuff?
>
> Unless the request sets .audit_skip, it'll be included already in terms
> of logging.
Neat.
> But I'd prefer not to lodge this in with ioctls, unless
> we're going to be doing actual ioctls.
Oh sure, I have been an advocate to ensure folks don't conflate async_cmd
with ioctl. However it *can* enable subsystems to enable ioctl
passthrough, but each of those subsystems need to vet for this on their
own terms. I'd hate to see / hear some LSM surprises later.
> But definitely something to keep in mind and make sure that we're under
> the right umbrella in terms of auditing and security.
Paul, how about something like this for starters (and probably should
be squashed into this series so its not a separate commit) ?
