From mboxrd@z Thu Jan 1 00:00:00 1970 From: Klaus Heinrich Kiwi Subject: [PATCH 00/07][RFC] RACF audit plugin Date: Fri, 28 Sep 2007 10:28:07 -0300 Message-ID: <1190986087.4113.49.camel@klausk.br.ibm.com> Reply-To: klausk@br.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux-audit@redhat.com, sgrubb@redhat.com List-Id: linux-audit@redhat.com List, the IBM z/OS v1R8 brings remote authorization and auditing capabilities to its 'Resource Access Control Facility' (RACF), through the implementation of two LDAP extended operations in the IBM Tivoli Directory Server (ITDS) - ITDS is the latest version of the z/OS LDAP server. The patches in the following messages implements a remote auditing plugin for RACF, targeting to forward events from the Linux audit subsystem for consolidation in a z/OS server. Please review. How it works: ============= Using the auparse_feed() interface, the plugin reads from stdin, feeding whatever gets in to the auparse_feed(). When a complete event is gathered, the 'push_event()' callback is called, which encodes the event into a BER buffer and pushes it to a queue (queue size can be configured). A second thread dequeues it and issues the LDAP extended operation, waiting for the response in a synchronous way. Once we got a response, we decode it and verify if the event submission was successful (we could skip this step right now since we're doing the submission in a 'best-effort' fashion, but its desirable to check whether the event got in or not right now, giving a better diagnosis of the reason). It is also desirable to keep the event for future submission in case of a network outage for example, although this deserves better thinking related to keeping a parallel audit log file. TODO list: ========== - SELinux policy (currently, the plugin runs under the audit daemon domain, which denies some network operations, for example) - Man page - code cleanups where possible - store-and-forward in case of network outages (design suggestions are welcome) - Fix queue issues in SIGHUP situations - Better integrate the plug-in into the audit.spec file Comments are very welcome, Klaus --