Proactive SELinux fixes from automatic collection of logs

John Dennis jdennis at redhat.com
Fri Jun 29 14:17:17 UTC 2007


On Fri, 2007-06-29 at 06:37 +0530, Rahul Sundaram wrote:
> Hi
> 
> There are many instances where SELinux policy causes AVC denials while 
> running programs. Some of these are policy issues, some actual bugs in 
> the program or security issues and others where the denial is rather 
> harmless and can be ignored for all practical purposes.
> 
> It is sometimes tedious to go and file a bug report methodologically on 
> all these denials in hope that we uncover and fix real policy issues. 
> What would be better is for users to run in some opt-in program that 
> automatically sends either the audit or messages log or both to central 
> server and the SELinux developers proactively fix policy issues without 
> the overhead of users filing bug reports.
> 
> I would gladly run a program and I would guess that many users would 
> find this a much better and easier way to report issues. We could even 
> tie this to a GUI and first boot in the installer. Kind of a smolt 
> (http://smolt.fedoraproject.org/stats) for SELinux if you will.  Comments?

We already have something much like you're suggesting. A while ago it
was recognized that diagnosing and addressing SELlinux AVC denials was a
significant problem. We designed and built a tool to help with that,
it's called setroubleshoot. It has a daemon that runs with root
priveleges and a user space desktop GUI component that will alert you to
any AVC denial and analyze it. You get a notification on your desktop
and GUI tool which allows you to browse your AVC denials in a user
friendly interpretation.

See: https://hosted.fedoraproject.org/projects/setroubleshoot

During the design phase of the tool we considered automatic bug
reporting and the design of the tool would support automatic bug
reporting. However, we elected to not implement automatic bug reporting
for the following reasons:

1) Not all AVC denials are bugs. In fact many are due to correctly
operations the sys admin must explicitly enable via a policy boolean.
One of the primary jobs of setroubleshoot is to automatically detect
these cases and tell the user how to configure the policy.

2) The information contained in an AVC denial is security sensitive. It
would be a huge security hole to automatically transmit any of this
information in the form of a bug report or other notification channel.

3) Automatic collection of user generated reports was an extra
development effort which also requires a central service. Implementing
the feature and resources to then manage this central service was deemed
out of scope, especially taking into consideration points 1 and 2 above.

The conclusion is that when user's see an AVC and have it automatically
interpreted (very easy with setroubleshoot) it is then up to them to
decide if it's really a bug (could just be policy configuration) and if
it is a bug if they want to export information which might be security
sensitive. If they elect to report then they can simply copy the report
out of the setroublehoot GUI and paste it into a bugzilla. 

Should there be a button which says "submit as bug report" in the GUI.
Sure that might be a very handy feature but at the moment bugzilla
requires an authenticated account to generate a new bug report. We also
don't want to flood bugzilla with duplicates via automated submission.
When setroubleshoot was designed it took the duplicate report issue into
account and it can recognize the same issue occuring on multiple systems
so that only one report would be generated. But that requires submitting
a setroubleshoot report to an intermediary central server which then
interacts with bugzilla.
-- 
John Dennis <jdennis at redhat.com>




More information about the fedora-selinux-list mailing list