Message-ID: <4269075.62B4Unzaoy@x2>
Date:	Thu, 29 May 2014 12:25:26 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	linux-audit@...hat.com, Eric Paris <eparis@...hat.com>,
	"H. J. Lu" <hjl.tools@...il.com>,
	"security@...nel.org" <security@...nel.org>,
	Philipp Kern <pkern@...gle.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

On Thursday, May 29, 2014 09:04:10 AM Andy Lutomirski wrote:
> On Thu, May 29, 2014 at 6:05 AM, Steve Grubb <sgrubb@...hat.com> wrote:
> > On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
> >> >>  - 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.
> > 
> > All syscalls must be auditable. Meaning that if an arch goes above 2048,
> > then we'll need to do some math to get it to fall back within the range.
>
> Off the top of my head, x32, some ARM variants, and some MIPS variants
> have syscalls above 2048.

That could be fixed by putting a subtraction in place to get the bit mask to 
map correctly. User space audit rules would need to fix that also.


> auditsc has been disabled on the offending
> ARM variant (because I noticed that the same issue affects seccomp,
> and no one particularly wants to fix it), but I suspect that auditsc
> is enabled but completely broken on whichever MIPS ABI has the issue.
> I haven't checked.
> 
> TBH, I think that it's silly to let the auditsc design be heavily
> constrained by ia64 considerations -- I still think that the syscall
> entry hooks could be removed completely with some effort on most
> architectures and that performance would improve considerably.  For
> users who don't have syscall filter rules, performance might even
> improve on ia64 -- I don't care how expensive syscall_get_args is, the
> actual printk/auditd thing will dominate in cases where anything is
> written.

The last time I heard of benchmarking being done, audit's performance hit was 
negligible. That was about 4 years ago and there has been a whole lot of code 
churn since then. But it should in general be the cost of an 'if' statement 
unless auditing is enabled. If it is enabled, then you necessarily get the 
full treatment in case you trigger an event.


> I wonder whether the syscall restart mechanism can be used to
> thoroughly confused auditsc.  I don't really know how syscall restarts
> work.
> 
> My point is: I don't know what guarantees auditsc is supposed to
> provide, nor do I know how to evaluate whether the code is correct.

There is an audit test suite that is used to verify that its working. Its not 
an exhaustive test suite, but it provides good coverage.


> For users who aren't bound by Common Criteria or related things, I
> suspect that syscall auditing (as opposed to, say, LSM-based auditing)
> will provide dubious value at best.

No, it works pretty good. You can see who is accessing what files pretty 
clearly.

> Keep in mind that many syscalls take pointer arguments, and the auditsc code
> can't really do anything sensible with them.

All security relevant information is collected in auxiliary records if they 
are not directly readable as a syscall argument. This is a basic requirement. 
We are not required to capture all possible arguments. If you know of any 
security relevant parameters not captured, please let us know.

-Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists