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. 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. 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? -- paul-moore.com
