Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

[Eric Paris]

On Wed, 2014-05-28 at 19:40 -0700, Andy Lutomirski wrote:
> On Wed, May 28, 2014 at 7:09 PM, Eric Paris <eparis@xxxxxxxxxx> 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...

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