Re: [PATCH v3 3/3] selinux: add permission names to trace event

[Stephen Smalley]

On Thu, Aug 20, 2020 at 10:22 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Tue, Aug 18, 2020 at 8:14 AM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> > On Tue, Aug 18, 2020 at 4:11 AM peter enderborg <peter.enderborg@xxxxxxxx> wrote:
>
> ...
>
> > > Is there any other things we need to fix? A part 1&2 now OK?
> >
> > They looked ok to me, but Paul should review them.
>
> Patches 1 and 2 look fine to me with the small nits that Stephen
> pointed out corrected.  I'm glad to see the information in string form
> now, I think that will be a big help for people making use of this.
>
> Unfortunately, I'm a little concerned about patch 3 for the reason
> Stephen already mentioned.  While changes to the class mapping are
> infrequent, they do happen, and I'm not very excited about adding it
> to the userspace kAPI via a header.  Considering that the tracing
> tools are going to be running on the same system that is being
> inspected, perhaps the tracing tools could inspect
> /sys/fs/selinux/class at runtime to query the permission mappings?
> Stephen, is there a libselinux API which does this already?

There is a libselinux API but both it and the /sys/fs/selinux/class
tree is exposing the policy values for classes/permissions, not the
kernel-private indices.  The dynamic class/perm mapping support
introduced a layer of indirection between them.  The tracepoint is in
the avc and therefore dealing with the kernel-private values, not the
policy values.  The mapping occurs on entry/exit of the security
server functions. So there is no way for userspace to read the kernel
class/perm values.  We'd just need to keep them in sync manually.  And
one is allowed to insert new classes or permissions before existing
ones, thereby changing the values of existing ones, or even to remove
them.