What, in the hopelessly complex chain of process startups, is supposed to start setroubleshootd? I find it is either not getting started or silently dieing on my Fedora 12 system. I find I've been getting a bunch of AVCs logged, with no alert of course, and no way to get those AVCs translated with human-readable timestamps so that I have the slightest chance of correlating those with anything else going on in the system. ("sealert -a /var/log/audit/audit.log" just dies with "NameError: global name 'avc' is not defined".)
The manpage for sealert mentions a GUI browser. That must have been in somebody's wet dream, because there is no such thing. Regardless of how sealert is started, the GUI menu discussed in the manpage does not exist.
Again, SElinux turns out to be a bigger pain than anything it is supposedly protecting against.
On Wed, Apr 21, 2010 at 01:34:16AM -0500, Robert Nichols wrote:
What, in the hopelessly complex chain of process startups, is supposed to start setroubleshootd? I find it is either not getting started or silently dieing on
Currently DBUS
my Fedora 12 system. I find I've been getting a bunch of AVCs logged, with no alert of course, and no way to get those AVCs translated with human-readable timestamps so that I have the slightest chance of correlating those with
ausearch -m avc -ts recent --interpret
anything else going on in the system. ("sealert -a /var/log/audit/audit.log" just dies with "NameError: global name 'avc' is not defined".)
The manpage for sealert mentions a GUI browser. That must have been in somebody's wet dream, because there is no such thing. Regardless of how sealert is started, the GUI menu discussed in the manpage does not exist.
Again, SElinux turns out to be a bigger pain than anything it is supposedly protecting against.
Please do not generalize, just because SETroubleshoot is not exactly a miracle that does not mean the rest of SELinux is a pain as well.
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
# sealert -a /var/log/audit/audit.log 11% doneTraceback (most recent call last): File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 635, in task self.new_audit_record_handler(record_type, event_id, body_text, fields, line_number) File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 661, in new_audit_record_handler self.avc_event_handler(audit_event) File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 647, in avc_event_handler avc = AVC(audit_event) File "/usr/lib64/python2.6/site-packages/setroubleshoot/audit_data.py", line 586, in __init__ self.derive_avc_info_from_audit_event() File "/usr/lib64/python2.6/site-packages/setroubleshoot/audit_data.py", line 884, in derive_avc_info_from_audit_event raise ValueError("Invalid AVC %s, it is allowed in current policy" % avc) NameError: global name 'avc' is not defined
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 04/21/2010 04:22 AM, Dominick Grift wrote:
On Wed, Apr 21, 2010 at 01:34:16AM -0500, Robert Nichols wrote:
What, in the hopelessly complex chain of process startups, is supposed to start setroubleshootd? I find it is either not getting started or silently dieing on
Currently DBUS
my Fedora 12 system. I find I've been getting a bunch of AVCs logged, with no alert of course, and no way to get those AVCs translated with human-readable timestamps so that I have the slightest chance of correlating those with
ausearch -m avc -ts recent --interpret
anything else going on in the system. ("sealert -a /var/log/audit/audit.log" just dies with "NameError: global name 'avc' is not defined".)
The manpage for sealert mentions a GUI browser. That must have been in somebody's wet dream, because there is no such thing. Regardless of how sealert is started, the GUI menu discussed in the manpage does not exist.
Again, SElinux turns out to be a bigger pain than anything it is supposedly protecting against.
Please do not generalize, just because SETroubleshoot is not exactly a miracle that does not mean the rest of SELinux is a pain as well.
When the analysis and reporting tools are not working, the entire glorious package becomes just another broken down luxury car blocking the center lane of the expressway and needing to be hauled away.
On Wed, Apr 21, 2010 at 09:48:26AM -0500, Robert Nichols wrote:
On 04/21/2010 04:22 AM, Dominick Grift wrote:
On Wed, Apr 21, 2010 at 01:34:16AM -0500, Robert Nichols wrote:
What, in the hopelessly complex chain of process startups, is supposed to start setroubleshootd? I find it is either not getting started or silently dieing on
Currently DBUS
my Fedora 12 system. I find I've been getting a bunch of AVCs logged, with no alert of course, and no way to get those AVCs translated with human-readable timestamps so that I have the slightest chance of correlating those with
ausearch -m avc -ts recent --interpret
anything else going on in the system. ("sealert -a /var/log/audit/audit.log" just dies with "NameError: global name 'avc' is not defined".)
The manpage for sealert mentions a GUI browser. That must have been in somebody's wet dream, because there is no such thing. Regardless of how sealert is started, the GUI menu discussed in the manpage does not exist.
Again, SElinux turns out to be a bigger pain than anything it is supposedly protecting against.
Please do not generalize, just because SETroubleshoot is not exactly a miracle that does not mean the rest of SELinux is a pain as well.
When the analysis and reporting tools are not working, the entire glorious package becomes just another broken down luxury car blocking the center lane of the expressway and needing to be hauled away.
Now youre comparing it to cars? You do not need setroubleshoot in the first place. You could simple uninstall it and use other analysis and reporting tools like aureport, audit2allow etc.
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2010 02:34 AM, Robert Nichols wrote:
What, in the hopelessly complex chain of process startups, is supposed to start setroubleshootd?
setroubleshootd is now a dbus service. It is supposed to be started when and AVC arrives or you start the sealert browser. It dies 10 seconds after the last connection/AVC arrival.
This link describes how it is supposed to work. http://danwalsh.livejournal.com/28828.html
Sounds like you might have found a bug in setroubleshoot. Setroubleshoot will also command suicide if the avc is about itself.
I find it is either not getting started or silently
dieing on my Fedora 12 system. I find I've been getting a bunch of AVCs logged, with no alert of course, and no way to get those AVCs translated with human-readable timestamps so that I have the slightest chance of correlating those with anything else going on in the system. ("sealert -a /var/log/audit/audit.log" just dies with "NameError: global name 'avc' is not defined".)
You can see the AVC's via ausearch.
ausearch -m avc -ts recent
To show recent avc's
ausearch -m avc -ts today
To show todays AVCs
The manpage for sealert mentions a GUI browser. That must have been in somebody's wet dream, because there is no such thing. Regardless of how sealert is started, the GUI menu discussed in the manpage does not exist.
Applications/System Tools/SELinux Troubleshooter sealert -b will launch the browser.
man sealert ... -b --browser Launch the browser
If the browser is blowing up you could just execute sealert -S
And see if it is throwing an exception.
Again, SElinux turns out to be a bigger pain than anything it is supposedly protecting against.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Send me the output of ausearch -m avc -ts today and I will see what is going on.
On 04/21/2010 08:02 AM, Daniel J Walsh wrote:
Send me the output of ausearch -m avc -ts today and I will see what is going on.
Last night, the audit log got rotated and "sealert -s" no longer crashes. Here's what I think occurred:
1. I got a bunch of AVCs (part of the "root procmail" problem).
2. I installed local policy to allow those actions.
3. sealert crashes when it encounters an old AVC that the current policy allows. Perhaps setroubleshootd is having the same problem. Now that logrotate has pushed out those pesky AVCs, no more crash. (Right now, auditd seems to have stopped logging new messages and has to be restarted, but that's an independent problem.)
I'll try to research this further, but coming up with a test case that can be easily reproduced on another system isn't going to be easy.
On 04/21/2010 10:04 AM, Robert Nichols wrote:
Last night, the audit log got rotated and "sealert -s" no longer crashes. Here's what I think occurred:
1. I got a bunch of AVCs (part of the "root procmail" problem). 2. I installed local policy to allow those actions. 3. sealert crashes when it encounters an old AVC that the current policy allows. Perhaps setroubleshootd is having the same problem. Now that logrotate has pushed out those pesky AVCs, no more crash. (Right now, auditd seems to have stopped logging new messages and has to be restarted, but that's an independent problem.)
I'll try to research this further, but coming up with a test case that can be easily reproduced on another system isn't going to be easy.
No, that's not what's doing it. I tracked it down to 1 line in the old audit.log file. Here's the killer:
type=AVC msg=audit(1265646923.059:12565): avc: denied { search } for pid=1557 comm="polkitd" name=".config" dev=sda2 ino=32945 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gnome_home_t:s0 tclass=dir
When "sealert -a" reads a file containing just that one line, the result is:
100% doneTraceback (most recent call last): File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 621, in task self.close() File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 608, in close self.avc_event_handler(audit_event) File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 647, in avc_event_handler avc = AVC(audit_event) File "/usr/lib64/python2.6/site-packages/setroubleshoot/audit_data.py", line 586, in __init__ self.derive_avc_info_from_audit_event() File "/usr/lib64/python2.6/site-packages/setroubleshoot/audit_data.py", line 884, in derive_avc_info_from_audit_event raise ValueError("Invalid AVC %s, it is allowed in current policy" % avc) NameError: global name 'avc' is not defined
selinux@lists.fedoraproject.org