On 8/13/20 5:49 PM, Stephen Smalley wrote:
> On 8/13/20 11:35 AM, peter enderborg wrote:
>
>> On 8/13/20 5:05 PM, Casey Schaufler wrote:
>>> On 8/13/2020 7:48 AM, Thiébaud Weksteen wrote:
>>>> From: Peter Enderborg <peter.enderb...@sony.com>
>>>>
>>>> This patch adds further attributes to the event. These attributes are
>>>> helpful to understand the context of the message and can be used
>>>> to filter the events.
>>>>
>>>> There are three common items. Source context, target context and tclass.
>>>> There are also items from the outcome of operation performed.
>>>>
>>>> An event is similar to:
>>>> <...>-1309 [002] .... 6346.691689: selinux_audited:
>>>> requested=0x4000000 denied=0x4000000 audited=0x4000000
>>>> result=-13 ssid=315 tsid=61
>>> It may not be my place to ask, but *please please please* don't
>>> externalize secids. I understand that it's easier to type "42"
>>> than "system_r:cupsd_t:s0-s0:c0.c1023", and that it's easier for
>>> your tools to parse and store the number. Once you start training
>>> people that system_r:cupsd_t:s0-s0:c0.c1023 is secid 42 you'll
>>> never be able to change it. The secid will start showing up in
>>> scripts. Bad Things Will Happen.
>> Ok, it seems to mostly against having this performance options.
>> Yes, it is a kernel internal data. So is most of the kernel tracing.
>> I see it is a primary tool for kernel debugging but than can also be
>> used for user-space debugging tools. Hiding data for debuggers
>> does not make any sense too me.
>
> 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).
>
Yes of course. Trace debugging is about running kernel. Would i make more sense
if the was a debugfs entry with the sid's? This filter are a reminisce of the
same filter used not only to catch denials. Doing a string compare
for all syscalls keep the cpu busy. I will do an update without it.
