[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <991d6a06-4b89-989a-92d1-82f295efe9bf@sony.com>
Date: Fri, 21 Aug 2020 07:53:36 +0200
From: peter enderborg <peter.enderborg@...y.com>
To: Paul Moore <paul@...l-moore.com>,
Stephen Smalley <stephen.smalley.work@...il.com>
CC: ThiƩbaud Weksteen <tweek@...gle.com>,
Nick Kralevich <nnk@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
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 8/21/20 4:22 AM, Paul Moore wrote:
> On Tue, Aug 18, 2020 at 8:14 AM Stephen Smalley
> <stephen.smalley.work@...il.com> wrote:
>> On Tue, Aug 18, 2020 at 4:11 AM peter enderborg <peter.enderborg@...y.com> 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?
>
One way to use this trace is to write directly to a memory buffer over a time
period. In the case for Android and I guess in many other embedded cases too
they are moved to be some other machine to be analysed so having them
locked to where it was running also have problems.
So what is the problem we see with the plugin, that we have perms names
that are "unknown" ?
Powered by blists - more mailing lists