Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 13 Aug 2020 13:38:42 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     peter enderborg <peter.enderborg@sony.com>
Cc:     Stephen Smalley <stephen.smalley.work@gmail.com>,
        Casey Schaufler <casey@schaufler-ca.com>,
        =?UTF-8?B?VGhpw6liYXVk?= Weksteen <tweek@google.com>,
        Paul Moore <paul@paul-moore.com>,
        Nick Kralevich <nnk@google.com>,
        Eric Paris <eparis@parisplace.org>,
        Ingo Molnar <mingo@redhat.com>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
        <linux-kernel@vger.kernel.org>, <selinux@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] selinux: add basic filtering for audit trace
 events
Message-ID: <20200813133842.655aff65@oasis.local.home>
In-Reply-To: <1b40226f-d182-7ba7-a6f6-15520c3e3516@sony.com>
References: <20200813144914.737306-1-tweek@google.com>
        <20200813144914.737306-2-tweek@google.com>
        <02c193e4-008a-5c3d-75e8-9be7bbcb941c@schaufler-ca.com>
        <a82d50bd-a0ec-bd06-7a3a-c2696398c4c3@sony.com>
        <c4424850-645f-5788-fb35-922c81eace6b@gmail.com>
        <1b40226f-d182-7ba7-a6f6-15520c3e3516@sony.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 13 Aug 2020 19:14:10 +0200
peter enderborg <peter.enderborg@sony.com> wrote:

> > To be clear, userspace tools can't use fixed secid values because
> > secids are dynamically assigned by SELinux and thus secid 42 need
> > not correspond to the same security context across different boots
> > even with the same kernel and policy.  I wouldn't include them in
> > the event unless it is common practice to include fields that can
> > only be interpreted if you can debug the running kernel.  It would
> > be akin to including kernel pointers in the event (albeit without
> > the KASLR ramifications).
> >
> >  
> Just as a reference on my fedora system; out of 1808 events 244 as a
> pointer print. I don't see that there is any obfuscating aka "%pK" as
> there is for logs.

Which is a reason why tracefs is root only.

The "%p" gets obfuscated when printed from the trace file by default
now. But they are consistent (where the same pointer shows up as the
same hash).

It's used mainly to map together events. For example, if you print the
address of a skb in the networking events, it's good to know what
events reference the same skb, and the pointer is used for that.

-- Steve