From owner-trustedbsd-discuss@FreeBSD.ORG Sat Sep 2 21:22:47 2006 Return-Path: X-Original-To: trustedbsd-discuss@freebsd.org Delivered-To: trustedbsd-discuss@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E573916A4DD for ; Sat, 2 Sep 2006 21:22:47 +0000 (UTC) (envelope-from csjp@FreeBSD.org) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 51D1243D45 for ; Sat, 2 Sep 2006 21:22:47 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: (qmail 15318 invoked by uid 86); 2 Sep 2006 21:52:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (204.112.0.40) by ems01.seccuris.com with SMTP; 2 Sep 2006 21:52:31 -0000 Message-ID: <44F9F626.5080307@FreeBSD.org> Date: Sat, 02 Sep 2006 16:22:46 -0500 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Kernel preselection of user supplied BSM record X-BeenThere: trustedbsd-discuss@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2006 21:22:48 -0000 Group, Lately I have been doing a lot of work on adding support to the kernel for parsing BSM records. Currently, when user supplied BSM records are unconditionally selected and show up in audit trails even if the trail (and now the pipe) is not interested in seeing it. We do have mechanisms in place to allow userspace to preselect, however this is only valid for the audit trail itself, and not pipes. I have made the following changes to our implementation: (1) We have two flags AR_PRESELECT_TRAIL and AR_PRESELECT_PIPE which tells the audit worker threads if we should be submitting the records. This was problematic in the sense that if the kernel was not interested in seeing the audit(2) record, the userspace record would be thrown away with it. Therefor I introduced two additional flags, AR_PRESELECT_USER_TRAIL and AR_PRESELECT_USER_PIPE which allows us to hold on the user supplied record, even if the kernel doesn't want to see the audit(2) record (2) Changed bsm_rec_verify() so that it checks to make sure basic components are present in the record to ensure it can be preselected properly, namely: header, subject, and return tokens. (3) Given the requirements in point 2, we had to be able to parse the BSM record in the kernel, meaning we had to understand how large each token was, so we introduced bsm_token_size() which when given a pointer to a token, returns it's size. This allowed us to introduce functions like bsm_get_header() and bsm_get_subject() et al to help us extract the information required for preselection. (4) Now audit(2) does the following, checks to see if the trail or any of the pipes are interested in the user supplied record, if not it frees the record and discards it. Otherwise, it sets the appropriate AR masks and initializes the preselection data (for pipes) in the kaudit structure and carries on. I have posted a link to the patch and would like some folks to review/comment. http://people.freebsd.org/~csjp/audit.1157061978.diff One of the challenges introduced by audit pipes is a lot of existing consumers of BSM i.e. OpenSSH perform their own preselection in userspace before submitting the record. So if an audit pipe is interested in retrieving a record, but the trail isnt, the record will not make it to the pipe. I propose that we teach the au_preselect() to query the kernel for an audit mask which represents that interest of all the active pipes and essentially OR'ing with the masks supplied by the configuration in /etc/security. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team