On Mon, Nov 21, 2022 at 11:53:17AM -0800, Luis Chamberlain wrote: > On Thu, Nov 17, 2022 at 05:10:07PM -0500, Paul Moore wrote: > > On Thu, Nov 17, 2022 at 4:40 AM Joel Granados <j.granados@xxxxxxxxxxx> wrote: > > > On Wed, Nov 16, 2022 at 02:21:14PM -0500, Paul Moore wrote: > > > > ... > > > > > > * As we discussed previously, the real problem is the fact that we are > > > > missing the necessary context in the LSM hook to separate the > > > > different types of command targets. With traditional ioctls we can > > > > look at the ioctl number and determine both the type of > > > > device/subsystem/etc. as well as the operation being requested; there > > > > is no such information available with the io_uring command > > > > passthrough. In this sense, the io_uring command passthrough is > > > > actually worse than traditional ioctls from an access control > > > > perspective. Until we have an easy(ish)[1] way to determine the > > > > io_uring command target type, changes like the one suggested here are > > > > going to be doomed as each target type is free to define their own > > > > io_uring commands. > > > > > > The only thing that comes immediately to mind is that we can have > > > io_uring users define a function that is then passed to the LSM > > > infrastructure. This function will have all the logic to give relative > > > context to LSM. It would be general enough to fit all the possible commands > > > and the logic would be implemented in the "drivers" side so there is no > > > need for LSM folks to know all io_uring users. > > > > Passing a function pointer to the LSM to fetch, what will likely be > > just a constant value, seems kinda ugly, but I guess we only have ugly > > options at this point. > > I am not sure if this helps yet, but queued on modules-next we now have > an improvement in speed of about 1500x for kallsyms_lookup_name(), and > so symbol lookups are now fast. Makes me wonder if a type of special > export could be drawn up for specific calls which follow a structure > and so the respective lsm could be inferred by a prefix instead of > placing the calls in-place. Then it would not mattter where a call is > used, so long as it would follow a specific pattern / structure with > all the crap you need on it. This is very good to know. Thx for putting this in the foreground. This problems CAN be seen as two: 1. Knowing where the io_uring is coming from (user, file, drivers...) 2. Calling the appropriate callback (ublk callback or nvme callback...) In this sense we might be able to use kallsysms_lookup_name() to do the callback to a relevant driver. I have posted a version 2 of the RFC without using kallsysms_lookup_name, but I'll keep it in the back of my mind. Best > > Luis
Attachment:
signature.asc
Description: PGP signature
