On 8/21/20 3:19 PM, Paul Moore wrote: > 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. > Ok.
