From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932213AbaE2Cy6 (ORCPT ); Wed, 28 May 2014 22:54:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16282 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755232AbaE2Cy5 (ORCPT ); Wed, 28 May 2014 22:54:57 -0400 Message-ID: <1401332086.13555.45.camel@localhost> Subject: Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text From: Eric Paris To: Andy Lutomirski Cc: Philipp Kern , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "H. J. Lu" , "security@kernel.org" , Greg Kroah-Hartman , linux-audit@redhat.com Date: Wed, 28 May 2014 22:54:46 -0400 In-Reply-To: References: <1401329367.13555.25.camel@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-05-28 at 19:40 -0700, Andy Lutomirski wrote: > On Wed, May 28, 2014 at 7:09 PM, Eric Paris wrote: > > NAK > > > > On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote: > >> Here are some issues with the code: > >> - It thinks that syscalls have four arguments. > > > > Not true at all. It records the registers that would hold the first 4 > > entries on syscall entry, for use later if needed, as getting those > > later on some arches is not feasible (see ia64). It makes no assumption > > about how many syscalls a function has. > > What about a5 and a6? On the couple of syscalls where a5 and a6 had any state that was actually wanted by someone (mainly just the fd on mmap) audit collects it later in the actual syscall. > >> - It assumes that syscall numbers are between 0 and 2048. > > > > There could well be a bug here. Not questioning that. Although that > > would be patch 1/2 > > Even with patch 1, it still doesn't handle large syscall numbers -- it > just assumes they're not audited. That's because we haven't had large syscall numbers. That's the whole point of an arch doing select HAVE_ARCH_AUDITSYSCALL. If they don't meet the requirements, they shouldn't be selecting it.... > >> - It's unclear whether it's supposed to be reliable. > > > > Unclear to whom? > > To me. > > If some inode access or selinux rule triggers an audit, is the auditsc > code guaranteed to write an exit record? And see below... This is an honest question: Do you want to discuss these things, or would you be happier if I shut up, fix the bugs you found, and leave things be? I don't want to have an argument, I'm happy to have a discussion if you think that will be beneficial...