On Fri, Aug 21, 2020 at 8:29 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Thu, Aug 20, 2020 at 10:31 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Wed, 19 Aug 2020 09:11:08 -0400 > > Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > > > > So we'll need to update this plugin whenever we modify > > > security/selinux/include/classmap.h to keep them in sync. Is that a > > > concern? I don't suppose the plugin could directly include classmap.h? > > > I guess we'd have to export it as a public header. It isn't considered > > > to be part of the kernel API/ABI and can change anytime (but in practice > > > changes are not that frequent, and usually just additive in nature). > > > > Yes, it would require some stability between userspace and the plugin. > > If the value indexes don't change then that would work fine. If you add > > new ones, that too should be OK, just have a way to state "unknown" in > > the plugin. > > Since we introduced the dynamic class/perm mapping support, it has > been possible for the values of existing classes/permissions to > change, and that has happened at time, e.g. when we added watch > permissions to the common file perms, that shifted the values of the > class file perms like entrypoint, when we added the process2 class > right after the process class, it shifted the values of all the > subsequent classes in the classmap.h. So you can't rely on those > values remaining stable across kernel versions. I think it is becoming increasingly clear that generating the permission set string in userspace isn't really workable without breaking the dynamic class/permission mapping to some degree. Unfortunately I don't see these perf changes as a big enough "win" to offset the loss of the dynamic mapping loss. I'm okay with merging patches 1/3 and 2/3 wth the changes Stephen suggested, but I think we will need to leave patch 3/3 out of this for now. -- paul moore www.paul-moore.com
