Bug 1215303

Summary: [Build 103.3] audit2allow not able to process tclass=(null)
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP5 Reporter: Joaquín Rivera <jeriveramoya>
Component: SecurityAssignee: Johannes Segitz <jsegitz>
Status: IN_PROGRESS --- QA Contact:
Severity: Normal    
Priority: P5 - None    
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://openqa.suse.de/tests/11730010/modules/audit2allow/steps/20
Whiteboard:
Found By: openQA Services Priority:
Business Priority: Blocker: Yes
Marketing QA Status: --- IT Deployment: ---
Attachments: audit2allow-audit.short.txt

Description Joaquín Rivera 2023-09-13 11:46:33 UTC 
Created attachment 869475 [details]
audit2allow-audit.short.txt

Command `cat /var/log/audit/audit.short.txt | audit2allow -M test_module` (when generating loadable module package from attached file) fails with parsing error:

libsepol.sepol_string_to_security_class: unrecognized class (null)
libsepol.sepol_string_to_security_class: unrecognized class (null)
compilation failed:
test_module.te:17:ERROR 'syntax error' at token '(' on line 17:
	class unix_stream_socket connectto;
	class (null) 0x2;
/usr/bin/checkmodule:  error(s) encountered while parsing configuration


The attached file is created in the test by picking the first 500 lines of the output of `audit2allow -i <file>`. See Perl test module for further info:
https://openqa.suse.de/tests/12095724/modules/audit2allow/steps/1/src

openQA failure:
https://openqa.suse.de/tests/12095724#step/audit2allow/20

last good openQA passing and expected behavior:
https://openqa.suse.de/tests/11052257#step/audit2allow/19

I could verify that removing the two lines containing "tclass=(null)" in the attached logs we obtain the desired behavior. In successful scenarios those lines do not appear. Seems that those parenthesis break the parser.

These are the two lines:

L11: type=USER_AVC msg=audit(1694523145.573:1524): pid=540 uid=499 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='avc:  denied  { 0x2 } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=9937 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=(null) permissive=1  exe=2F7573722F62696E2F646275732D6461656D6F6E202864656C6574656429 sauid=499 hostname=? addr=? terminal=?'


L48: type=USER_AVC msg=audit(1694523160.477:1561): pid=540 uid=499 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='avc:  denied  { 0x2 } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=10022 scontext=system_u:system_r:wicked_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=(null) permissive=1  exe=2F7573722F62696E2F646275732D6461656D6F6E202864656C6574656429 sauid=499 hostname=? addr=? terminal=?'
Comment 1 Joaquín Rivera 2023-09-13 11:56:43 UTC 
The problem was seen in Quarter update for SLE 15 SP5, but in development product for SLE 15 SP6 or maintenance product SLE 15 SP5 the problem is not present because those kind of lines do no appear in the logs:
https://openqa.suse.de/tests/12101761#step/audit2allow/19
https://openqa.suse.de/tests/11986707#step/audit2allow/19

Is this something already fixed? or perhaps we will see it sporadically in the future. It would be good to know that that kind of lines are there wrongly for some reason or if the parser needs adjustments to be able to process them. wdyt?
Comment 2 Johannes Segitz 2023-09-13 12:25:35 UTC 
since this is a USER_AVC I think this might be something in DBUS and not a problem with SELinux, but I need to have a deeper look
Comment 3 Johannes Segitz 2023-11-28 10:22:01 UTC 
sorry, I assigned myself but didn't put it on my list, so I forgot about this. 

I now looked into this. I can't reproduce the problem, but it seems stable on openQA. This happens still in permissive mode and probably during early boot. Something generates broken audit entries, tclass should not be null. 

I'll try to figure out how this happens, but I'm starting to run out of ideas
Comment 4 Johannes Segitz 2023-11-29 10:51:04 UTC 
That is some weird issue. I spent a lot of time in reproducing this. Locally it doesn't happen at all. In openQA I can reproduce it, but it vanishes when I e.g. grep for AVCs before rebooting, which doesn't make sense at all.

I try to rework the test case so that this isn't triggered anymore, because unless I can reproduce this I'm not able to do much more about this
Comment 5 Johannes Segitz 2023-11-29 12:35:27 UTC 
No clue why this works, but it does:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18223