Having setroubleshootd and sealert both in the top 7 memory processes on a Fedora 10 system, is not good. The livecd guys also complain about the amount of memory setroubleshoot is using. Anyone building small memory systems can not use setroubleshoot. To make things worse, both of these applications are sitting idle most of the time. setroubleshootd is waiting for AVCs from the audit system and sealert is waiting for setroubleshood to tell it to put up the star.
These two programs use this much memory because they are written in Python. I did not want to rewrite the bulk of this code in C, especially since the plugins are all in python, I hate writing C, and rewriting setroubleshoot was not a priority.
I wanted to change the code so that the python code was running only when the user was actively using the browser or setroubleshootd was processing an AVC.
First I wrote seapplet, which is just a C program that listens for DBus signals from setroubleshootd, and then puts up the star. If the user clicks on the star, seapplet launches the sealert browser, which talks to setroubleshootd, the same way it always has. This eliminated the need to run sealert all of the time, and used a fraction of the memory, but I still had setroubleshootd running.
Next, I changed sealert to use DBus activation to launch setroubleshootd. I wrote a new audit plugin in C, sedispatch, with the help of Steve Grubb. This plugin gets all messages from the audit system and uses the audit library to search for AVC messages. When it finds an AVC message, it uses DBus to forward the AVC message to setroubleshootd. DBus starts setroubleshootd if it is not running. I added an alarm to setroubleshootd to shut it down if no one is connected to it and it has not received an AVC message for 10 seconds. This prevents setroubleshoot starting and stopping if a flood of AVC messages comes in.
Fedora 11/Rawhide has the new version of setroubleshoot.
On a freshly installed F11 system sedispatch will be running waiting for an AVC message, and if a user is logged in seapplet will be running in the task bar.
Next I would like to make some GUI enhancements to setroubleshoot. Máirín Duffy has made some nice mock ups of a new GUI. If anyone wants to try their hand at python coding, patches will be gladly accepted. Volunteers???
Finally I would like to get to the point where setroubleshoot could differentiate between harmless SELinux failures and AVCs that clearly indicate an intruder. For example, no confined domain should ever attempt to turn SELinux enforcing mode off. If the system ever sees this AVC, it should indicate with a red star that something really bad is happening and should advise the user to take immediate action.