Bug 475978

Forgot to say the obvious - of course there should be an "advanced" button so that power-users can still actually analyse the denial themselves.

We are working on a redesign of the GUI.  Which includes:

* simplification of the messages
* "Report Bug" button, 
* Perhaps a "Fix" button.
* Higher Alert status, on suspected intruder, IE Certain denials should never happen in the normal running of a system, and truly doe suggest an intruder, for example a confined application attempting to turn off selinux.
* A review of all report plugins by a doc writer to make sure they are humanly readable.

Other changes planned, are to reduce the memory foot print of setroubleshoot and make it more of a on demand, Only run the service when a alert comes in or the browser is running.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I second that.

I just installed F11. Current setroubleshoot behavior is not useful. It shows tons of information. I read it all, and I still can't figure out what is the problem. I can't even understand what file or directory it complains about.

And I am not an ordinary user. I wonder what ordinary users think when they see it.

I will likely just disable selinux, just as I did when I installed F9. It seems to only cause frustration.

Denys Please send me your /var/log/audit/audit.log and I can help you out.

dwalsh, most likely a labeling problem.

Current rawhide version of setroubleshoot has most of the fixes that you have suggested,  one thing we are looking into now is hooking up setroubleshoot to package kit to check for the availability of newer selinux-policy package, so it could at least suggest an upgrade.

Created attachment 353848 [details]
My /var/log/audit/audit.log

Well I would guess Denys you have a badly labeled system


# fixfiles restore

should fix the labeling.

You have /dev/log mislabeled for some reason.  

You also have busybox in non default directory under /?

(In reply to comment #8)
> Well I would guess Denys you have a badly labeled system
> 
> # fixfiles restore
> 
> should fix the labeling.
> 
> You have /dev/log mislabeled for some reason.

and I wasn't able to decipher it from setroubleshoot's information. This is what this bugzilla entry is about.

But setroubleshoot can only attempt to figure out what is wrong with each avc.  I am pretty sure it told you to run restorecon on many of your AVC's.  When a machine is totally mislabeled, setroubleshoot does not stand much of a chance of figuring out what is wrong.  Did you try to relabel the machine?  Did this fix your problem?

(In reply to comment #10)
> But setroubleshoot can only attempt to figure out what is wrong with each avc. 
> I am pretty sure it told you to run restorecon on many of your AVC's.

No, it did not. That's why I am commenting in this particular bug, which is titled "setroubleshoot usability improvements". Because when I looked at its warnings as a user, I was confused.

I was looking at one avc report, and it did not tell me which file is mislabeled. I understand that the program cannot say "gee, I see you have many files mislabeled, please do XYZ". But it did not even say "file /foo/bar is mislabeled".

> When a
> machine is totally mislabeled, setroubleshoot does not stand much of a chance
> of figuring out what is wrong.

Can it at least say what file is mislabeled _for this particular_ avc?

> Did you try to relabel the machine?  Did this fix your problem?

I just disabled SELinux.

The trouble we have had in the past with the kernel is the kernel does not give the troubleshooter the full path, so it gives us something like name=passwd along with the inode, so we can not always figure out the kernel meant /etc/passwd.  In Rawhide now, we actually have setroubleshoot taking passwd and running locate on it, to find all files on the system named locate, then checking the inode number on each one to compare to the inode in the AVC.  If we can reassemble the path, we will get a much better hit rate on whether or not the file is mislabeled. 

The kernel will also only hand us a "/" for a path on mount points.  Which confuses setroubleshoot.  For example if you put your home directories in a directory /h and mounted a mount point there.  SELinux would default that label to default_t, since it defaults all unknown root directories as default_t.  Now if a confined application like httpd tried to read content in a users homedir, it would generate an avc that says something like

httpd_t can not read the "/" directory labled default_t.

We are trying to make setroubleshoot figure out what the kernel meant by this by looking at the device and /proc/mounts to figure out the kernel meant "/h"  Which would allow us to give the user a much better description of the problem.

THese are two enhancments that are coming in F12, and I might put out as a testing update in F11.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fixed in setroubleshoot-2.2.52-1.fc12