Proactive SELinux fixes from automatic collection of logs

[Rahul Sundaram]

John Dennis wrote:
> 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. 

This requires a GUI right? My idea would work on any Fedora system.

> 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.

This is in fact one of my reasons for favoring a more automated 
collection of AVC denials. Some of the systems don't have any GUI and I 
don't report bugs unless it prevents programs from working correctly. 
Maybe there are policy improvements to be made but it is not worth the 
trouble in many occasions to go and file bug reports for every AVC denial.

> 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.

Encrypt it before transmission and scrub the data before revealing 
anything. Also this concern is already somewhat offset from the effort 
described below.

> 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.

Since there is a effort now to create infrastructure that allows people 
to upload logs and get analysis it wouldn't be too much additional 
effort. Smolt also already has similar infrastructure in place which 
would be a good example to learn from.

Rahul