On Mon, Nov 21, 2022 at 04:05:37PM -0500, Paul Moore wrote: > On Mon, Nov 21, 2022 at 2:53 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> 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. > > I suspect we may be talking about different things here, I don't think > the issue is which LSM(s) may be enabled, as the call is to > security_uring_cmd() regardless. I believe the issue is more of how > do the LSMs determine the target of the io_uring command, e.g. nvme or > ublk. I agree, but we might be able to use kallsysms_lookup_name to execute a callback once we know where the call comes from. > > My understanding is that Joel was suggesting a change to the LSM hook > to add a function specific pointer (presumably defined as part of the > file_operations struct) that could be called by the LSM to determine > the target. Indeed. I just sent out the RFC. Its at an idea stage and would be great to hear what you think > > Although now that I'm looking again at the file_operations struct, I > wonder if we would be better off having the LSMs inspect the > file_operations::owner field, potentially checking the module::name > field. It's a little painful in the sense that it is potentially > multiple strcmp() calls for each security_uring_cmd() call, but I'm > not sure the passed function approach would be much better. Do we > have a consistent per-module scalar value we can use instead of a > character string? This is also a possibility. And with that we might just be able to call some sort of callback with kallsysms_lookup_name or whatever makes sense. > > -- > paul-moore.com
Attachment:
signature.asc
Description: PGP signature
