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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Aug 2020 20:18:55 +0200
From:   peter enderborg <>
To:     Steven Rostedt <>
CC:     Stephen Smalley <>,
        Casey Schaufler <>,
        Thiébaud Weksteen <>,
        Paul Moore <>,
        Nick Kralevich <>,
        Eric Paris <>,
        Ingo Molnar <>,
        Mauro Carvalho Chehab <>,
        "David S. Miller" <>,
        Rob Herring <>, Arnd Bergmann <>,
        <>, <>
Subject: Re: [PATCH v2 2/2] selinux: add basic filtering for audit trace

On 8/13/20 7:38 PM, Steven Rostedt wrote:
> On Thu, 13 Aug 2020 19:14:10 +0200
> peter enderborg <> 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.

So what is your opinion on ssid? I dont mind removing them
now since people dont like it and the strong use-case is not
strong (yet). Is there any problem to put getting them back
later if useful? And then before the strings so the evaluation
of filter first come on number before stings Or is there already
some mechanism that optimize for that?

> -- Steve

Powered by blists - more mailing lists