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 report? > > 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@xxxxxxxxxx> -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
