On Tue, Jul 28, 2020 at 6:20 PM Paul Moore wrote:
> I probably wasn't as clear as I should have been. I think it would be
> helpful if you demonstrated how one would take the SELinux data in the
> perf event and translated that into something meaningful.
So the data itself is not that relevant.
On 7/28/20 6:02 PM, Thiébaud Weksteen wrote:
> On Tue, Jul 28, 2020 at 5:12 PM Paul Moore wrote:
>> Perhaps it would be helpful if you provided an example of how one
>> would be expected to use this new tracepoint? That would help put
>> things in the proper perspective.
> The best example is the
On Tue, Jul 28, 2020 at 12:02 PM Thiébaud Weksteen wrote:
> On Tue, Jul 28, 2020 at 5:12 PM Paul Moore wrote:
> > Perhaps it would be helpful if you provided an example of how one
> > would be expected to use this new tracepoint? That would help put
> > things in the proper perspective.
>
> The
On 7/28/20 12:02 PM, Thiébaud Weksteen wrote:
On Tue, Jul 28, 2020 at 5:12 PM Paul Moore wrote:
Perhaps it would be helpful if you provided an example of how one
would be expected to use this new tracepoint? That would help put
things in the proper perspective.
The best example is the one I
On Tue, Jul 28, 2020 at 5:12 PM Paul Moore wrote:
> Perhaps it would be helpful if you provided an example of how one
> would be expected to use this new tracepoint? That would help put
> things in the proper perspective.
The best example is the one I provided in the commit message, that is
usin
On Fri, Jul 24, 2020 at 5:15 AM Thiébaud Weksteen wrote:
>
> The audit data currently captures which process and which target
> is responsible for a denial. There is no data on where exactly in the
> process that call occurred. Debugging can be made easier by being able to
> reconstruct the unifie
On Tue, Jul 28, 2020 at 8:49 AM Thiébaud Weksteen wrote:
>
> Thanks for the review! I'll send a new revision of the patch with the
> %x formatter and using the TP_CONDITION macro.
>
> On adding further information to the trace event, I would prefer
> adding the strict minimum to be able to correla
On Tue, Jul 28, 2020 at 3:12 PM Steven Rostedt wrote:
> Where in that document does it say that trace events have a fixed size.
> We have a lot of dynamically sized trace events.
My mistake. From the "format" pseudo-file, I assumed the offset and
size were fixed.
> Please take a look at samples/
On Tue, Jul 28, 2020 at 3:04 PM Stephen Smalley
wrote:
> Ok, also please use unsigned int for the fields and %u for the cls value.
Will do in v3. Thanks.
On Tue, 28 Jul 2020 14:49:24 +0200
Thiébaud Weksteen wrote:
> Thanks for the review! I'll send a new revision of the patch with the
> %x formatter and using the TP_CONDITION macro.
>
> On adding further information to the trace event, I would prefer
> adding the strict minimum to be able to corr
On 7/28/20 8:49 AM, Thiébaud Weksteen wrote:
Thanks for the review! I'll send a new revision of the patch with the
%x formatter and using the TP_CONDITION macro.
On adding further information to the trace event, I would prefer
adding the strict minimum to be able to correlate the event with the
Thanks for the review! I'll send a new revision of the patch with the
%x formatter and using the TP_CONDITION macro.
On adding further information to the trace event, I would prefer
adding the strict minimum to be able to correlate the event with the
avc message. The reason is that tracevents have
On Fri, Jul 24, 2020 at 9:32 AM Stephen Smalley
wrote:
> On Fri, Jul 24, 2020 at 5:15 AM Thiébaud Weksteen wrote:
> > The audit data currently captures which process and which target
> > is responsible for a denial. There is no data on where exactly in the
> > process that call occurred. Debuggin
On Fri, 24 Jul 2020 11:15:03 +0200
"Thiébaud Weksteen" wrote:
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index d18cb32a242a..85d2e22ab656 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -31,6 +31,9 @@
> #include "avc_ss.h"
> #include "classmap.h"
>
On Fri, Jul 24, 2020 at 5:15 AM Thiébaud Weksteen wrote:
>
> The audit data currently captures which process and which target
> is responsible for a denial. There is no data on where exactly in the
> process that call occurred. Debugging can be made easier by being able to
> reconstruct the unifie
The audit data currently captures which process and which target
is responsible for a denial. There is no data on where exactly in the
process that call occurred. Debugging can be made easier by being able to
reconstruct the unified kernel and userland stack traces [1]. Add a
tracepoint on the SELi
16 matches
Mail list logo
