Hide Forgot
Description of problem: I am working RHEL6.1 ja_JP Desktop. Frequently SELinux alerts occur but when I see sealert GUI, there is not message to report. In /var/log/messages there are logs below but described command 'sealert -l <id>' returns id not found. Apr 4 10:37:13 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l 04d6a653-f1df-4630-bc20-1408bd9c1ccc Apr 4 10:37:13 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l 04d6a653-f1df-4630-bc20-1408bd9c1ccc Apr 7 09:36:35 dhcp-1-167 setroubleshoot: SELinux は /usr/sbin/tzdata-update による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l 42128f12-361a-4489-b386-12315457b535 Apr 7 09:36:35 dhcp-1-167 setroubleshoot: SELinux は /usr/sbin/tzdata-update による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l 42128f12-361a-4489-b386-12315457b535 # sealert -l 04d6a653-f1df-4630-bc20-1408bd9c1ccc query_alerts error (1003): id (04d6a653-f1df-4630-bc20-1408bd9c1ccc) not found # sealert -l 42128f12-361a-4489-b386-12315457b535 query_alerts error (1003): id (42128f12-361a-4489-b386-12315457b535) not found Apart from why SELinux detects above "dac_override" access errors, I think sealert GUI or CLI should provide some info about how to fix the issue. Version-Release number of selected component (if applicable): $ rpm -qa | grep setroubleshoot setroubleshoot-server-2.2.94-1.el6.i686 setroubleshoot-plugins-2.1.60-1.el6.noarch setroubleshoot-2.2.94-1.el6.i686 How reproducible: SELinux alert sometimes occurs. Steps to Reproduce: 1. Do some routine tasks on RHEL6.1 ja_JP Desktop such as browsing. 2. Sometimes SELinux alerts occur. 3. Click alert icon on the Panel. 4. Run command described in /var/log/messages Actual results: Neither sealert GUI or CLI show any usable information. Expected results: sealert GUI or CLI should provide some info about how to fix the issue. Additional info:
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Is this a translation problem? IE Can you try those commands with LANG=C and see if it works? Sometimes those commands could fail if the alert has been removed from the database. Alerts get removed if more then 50 different alerts get added. Or if a policy update fixes the problem.
Hi I do not think this is an i18n issue. At least regarding 'sealert', as below it cannot find most recent incident id. $ sudo tail -20 /var/log/messages | grep setroubleshoot Apr 8 11:38:14 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 Apr 8 11:38:14 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 Apr 8 11:40:24 dhcp-1-167 setroubleshoot: [xml.ERROR] read_xml_file() libxml2.parserError: xmlParseFile() failed $ sudo LANG=C sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found $ sudo LANG=ja_JP.UTF8 sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found $ su パスワード: # LANG=C # sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found # LANG=en_US.UTF8 # sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found
Please attach /var/lib/setroubleshoot/audit_listener_database.xml This xml database is what sealert is trying to read.
Created attachment 491119 [details] audit_listener_database.xml Please find attached, thanks
Fixed in setroubleshoot-3.0.31-1.el6
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Under certain circumstances, when the setroubleshoot utility detected alerts, the sealert utility was not able to display appropriate error messages and the "sealert -l" command returned the "id not found" error message. This bug has been fixed in this update so that sealert now works as expected.
If a common user runs "sealert -b" and deletes all alerts which are shown in the browser window then these alerts stop being visible for root user too. Which means that "sealert -l ..." will always produce following message: query_alerts error (1003): id (...) not found I would say that this behavior is a bug. Alerts written by setroubleshootd to /var/log/messages should be always visible for root.
Is it possible that another user deleted some alerts via sealert browser window as described in comment#11 ?
You can prevent common users from deleteing the alerts if you want by modifying setroubleshoot config.
Hi Dan, how to prevent users from deleting alerts? By restriction of "client_users = *" in /etc/setroubleshoot/setroubleshoot.conf? Do you think that the default behavior (user can delete the alert) is fine?
Yes that will work. Being able to delete alerts, is not changing the log files. The AVC still exists in the audit.log and perhaps referred to in the /var/log/messages. But if I had a multi-user machine, I would worry more about information leaks and might remove the setroubleshoot package and just leave the setroubleshoot-server package.
The thing is that ordinary user can delete the alert but not to remove the setroubleshoot package. Once the alert is deleted, it is difficult to match the warning in /var/log/messages to the audit.log record. Admin user cannot use id , the only option that comes to my mind right now is to "decrypt" the timestamp in audit.log.
How Dan said, the AVC msgs are available from audit.log for root user. If a root user doesn't want to allow a common user to remove alerts then there is an option.
In that case this bug should be closed as NOT_A_BUG. Unless I am missing something.
Per all comments I am closing this bug as NOTABUG.