Re: [PATCH] RFC: selinux avc trace

From: peter enderborg <peter.enderborg@sony.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
	"Thiébaud Weksteen" <tweek@google.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Nick Kralevich" <nnk@google.com>,
	"Joel Fernandes" <joelaf@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>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"SElinux list" <selinux@vger.kernel.org>
Subject: Re: [PATCH] RFC: selinux avc trace
Date: Thu, 30 Jul 2020 17:47:21 +0200	[thread overview]
Message-ID: <b2bde77e-98cf-2c62-79ed-ca7d58b10bca@sony.com> (raw)
In-Reply-To: <CAEjxPJ5tu=R20snbetzv+CCZMd-yD+obbkbf6MYVqQx3oZLkqA@mail.gmail.com>

On 7/30/20 4:50 PM, Stephen Smalley wrote:
> On Thu, Jul 30, 2020 at 10:29 AM peter enderborg
> <peter.enderborg@sony.com> wrote:
>> I did manage to rebase it but this is about my approach.
>>
>> Compared to Thiébaud Weksteen patch this adds:
>>
>> 1 Filtering. Types goes to trace so we can put up a filter for contexts or type etc.
>>
>> 2 It tries also to cover non denies.  And upon that you should be able to do coverage tools.
>> I think many systems have a lot more rules that what is needed, but there is good way
>> to find out what.  A other way us to make a stat page for the rules, but this way connect to
>> userspace and can be used for test cases.
>>
>> This code need a lot more work, but it shows how the filter should work (extra info is not right)
>> and there are  memory leaks, extra debug info and nonsense variable etc.
> Perhaps the two of you could work together to come up with a common
> tracepoint that addresses both needs.

Sounds good to me.

> On the one hand, we don't need/want to duplicate the avc message
> itself; we just need enough to be able to correlate them.
> With respect to non-denials, SELinux auditallow statements can be used
> to generate avc: granted messages that can be used to support coverage
> tools although you can easily flood the logs that way.  One other

That is one reason to use trace. I can be used for things that
generate a lot of data. Like memory allocations and scheduler etc,
and it is a developer tool so you should not have to worry about DOS etc.

Both netlink and android logging are too happy to throw away data for
developers to be happy.

> limitation of the other patch is that it doesn't support generating
> trace information for denials silenced by dontaudit rules, which might
> be challenging to debug especially on Android where you can't just run
> semodule -DB to strip all dontaudits.

I think that only work for rooted devices. Many application developers
run on commercial devices that are locked, but they do have access
to trace. But I have no idea if they (google) have intended the selinux traces to
available there.