On Mon, Nov 28, 2022 at 11:13:29AM +0100, Joel Granados wrote: > On Tue, Nov 22, 2022 at 10:04:03PM +0800, Ming Lei wrote: > > 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. > > > > > > 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? > > > > In future there may be more uring_cmd kernel users, maybe we need to > > consider to use one reserved field in io_uring_sqe for describing the > > target type if it is one must for security subsystem, and this way > > will be similar with traditional ioctl which encodes this kind of > > info in command type. > This is of course another option. I was a bit reluctant to start the > discussion with this implementation, but now that you have brought it up > I can come up with an initial RFC and we can add it to the mix of > possibilities. > > Would you just add it to the end of the struct? or what reserved field > are you referring to? io_uring_sqe is uapi, so you can't add any field to sqe, and '__pad1' could be best field for carrying this info, given it is close to 'cmd_op', and 'u8' should be enough for storing target type info. thanks, Ming
