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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Aug 2020 08:29:21 -0400
From:   Stephen Smalley <stephen.smalley.work@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thiébaud Weksteen <tweek@...gle.com>,
        Paul Moore <paul@...l-moore.com>,
        Nick Kralevich <nnk@...gle.com>,
        Peter Enderborg <peter.enderborg@...y.com>,
        Eric Paris <eparis@...isplace.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        SElinux list <selinux@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] selinux: add permission names to trace event

On Thu, Aug 20, 2020 at 10:31 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Wed, 19 Aug 2020 09:11:08 -0400
> Stephen Smalley <stephen.smalley.work@...il.com> 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.