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