Description of problem: An appropriately privilege user (CAP_SYS_ADMIN) can perform various control actions on the audit system with an ioctl() on /dev/audit. One of these is the ability to detach a process from the audit system. These control events are not themselves audited. For the most part it is possible to work round this by auditing ioctl calls on /dev/audit. However, for detach specifically and also resume this does not work. This opens a severe hole in the ability of the audit system to audit operations on itself. Version-Release number of selected component (if applicable): 2.4.21-47.0.1.EL How reproducible: Always Steps to Reproduce: 1. Create a program which detaches itself from laus by calling laus_detach(). 2. Invoke the program. Actual results: There is no audit configuration which will audit this. Expected results: Should probably be audited by default.
Created attachment 149877 [details] Patch against kernel 2.4.21-47.0.1.EL to add audit control events This patch adds a new event type for audit control events. The events are generated for every attempted ioctl on /dev/audit. The event comprises: * the ioctl request number * the return code The events are only generated based on a match in the filter policy. This means that existing configurations will not receive these events. In fact, without the corresponding laus userspace update, it is not possible to receive these events. With the userspace update, receiving these events simply requires the following line in filter.conf: event audit-control = always;
Created attachment 149955 [details] Patch against kernel 2.4.21-47.0.1.EL to add audit control events This is an NFC from the previous patch. It fixes a coding style problem found by Brynn Reeves (spaces instead of a tab).
Reviewed patch and have 1 comment: + error=-EPERM; <snip> + goto error; Might not be good to have a variable "error" and a label of "error". The label could be error_exit, err, or something else that's unique.
Created attachment 150254 [details] goto error -> goto err Agreed. Attaching revised patch.
A fix for this problem has just been committed to the RHEL3 U9 patch pool this evening (in kernel version 2.4.21-47.7.EL).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0436.html
Resolved. Closing ticket. Internal Status set to 'Resolved' Status set to: Closed by Tech Resolution set to: 'RHEL 3.9' This event sent from IssueTracker by jfautley issue 116053