Proactive SELinux fixes from automatic collection of logs
jdennis at redhat.com
Mon Jul 2 17:48:31 UTC 2007
On Mon, 2007-07-02 at 22:30 +0530, Rahul Sundaram wrote:
> John Dennis wrote:
> > 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.
No a GUI is not required, setroubleshoot-server can be installed on a
headless machine. In this configuration the alerts setroubleshoot
generates can be sent via email or one can use sealert in either the GUI
or the command line mode to connect to the remote node and view the
analysis or one can ssh into the machine and use the command line mode
of sealert. That means at the moment there are 3 different ways you can
get setroubleshoot analysis from a machine without an installed GUI.
There are probably more favorable ways of gathering the data from
setroubleshoot when managing a collection of nodes. We do have a
requirement to better support general auditing from a collection of
nodes. Work is proceeding on that front and the plans are to have
setroubleshoot be a component in 'aggregate auditing.
> > 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.
Just one problem here, who is going to be responsible for triaging every
AVC denial on every installed Fedora system to figure out if it's user
error, noise, or a genuine issue? The sheer volume would be
overwhelming. One need only consider how long many genuine bugs languish
in bugzilla due to inattention and one has to question just what
forwarding all AVC denials is going to accomplish in practical terms.
Putting an intelligent human in between the denial event and a bug
report gains enormous efficiency right?
> > 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.
Automatically sending security information to a remote third party is
not going to be accepted by most users and certainly could not be
enabled by default. If automatic transmission is not enabled by default
then what is gained over an administrator of the system being
automatically notified of a denial by setroubleshoot and letting them
evaluate if this particular AVC denial needs to be elevated to a bug
> > 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.
I will take a look a smolt to see what it offers and what it's model is.
Perhaps there are things in smolt we could benefit from.
John Dennis <jdennis at redhat.com>
More information about the fedora-selinux-list