[RFC] Future audit changes

[Steve Grubb]

Hello,

I am considering making some drastic changes in a future 4.0 release. This is 
partly motivated by a change in my daytime job. I am no longer working in Red 
Hat security. Therefore working on audit is officially a hobby. I have spent 
the last weeks closing out pull requests and Issues so that whoever wants to 
contribute to the audit project doesn't have a lot of history to deal with. 
There's almost 500 people subscribed to this list. The community needs to 
step up a little.

The proposed changes are:

1) Drop support for Python 2. Python 2 has lost upstream support over 3 years 
ago. I also can't see the viability of someone saying they need the latest 
audit changes for the new kernel yet they are stuck on python 2. It doesn't 
compute. This is also related to proposal 5 below.

2) Drop SysVinit support. I think everyone has changed to systemd at this 
point. This is to reduce potential maintenance.

3) This is probably the most controversial and would need careful testing: 
Split the audit service into 2 services: auditd and rules-load. These would 
be packaged in 2 different packages so that if all you want is rules-loading 
and are fine with events going to journald - have at it. If you want the 
tradition audit experience, then install the audit package which will depend 
on the rules package. The trick is making them automatically enabled at 
install. This will need testing and perhaps patches. Packagers will need to 
work with their distribution  to update systemd presets.

4) Change the definition of which events are simple (one record events) and 
compound (multiple records per event). Over the years syscall records were 
added to the simple events haphazardly. That seems to have settled down and 
we can redefine which are in which group. This is important because this 
determines when an event is complete and ready to process in ausearch,  
aureport, and auparse. This should reduce future bug reports.

5) Drop functions from libaudit python bindings that have anything to do with 
placing and removing rules in the kernel. I'd like the API to just contain 
what's needed to send audit events and query kernel status. This new binding 
would be hand written, thus possibly breaking compatibility with the swig 
generated bindinsg. Not 100% sure on that, but it might be a side effect. The 
main idea is limit the scope to reduce maintenance and future-proof kernel/
swig changes.

6) Moratorium on new arches being supported. If someone else comes along and 
really shows *sustained* support for the audit project for a while and they 
want a new arch to be supported, I might consider it. Since my work on this 
project is now a hobby, I am not inclined to make more work for my weekends.

7) Drop the autrace & auvirt programs. Does anyone actually use these? Can 
ausearch take the place of auvirt? The aim here is reduce maintenance.

Let me know what you think. I'll probably put these in a new audit-4.0 branch 
until they are complete and some testing has been done.

-Steve