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

[Andy Lutomirski]

On Wed, May 28, 2014 at 7:54 PM, Eric Paris <eparis@xxxxxxxxxx> wrote:
> 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...
>

I'm happy to discuss these things.  I'd be happy if you fix things.  I
think that there are two major issues affecting users of auditsc and
that either those issues should be fixed or users of auditsc should
understand and accept these issues.

Issue 1: syscall numbering.  The syscall filters are unlikely to work
well on lots of architectures.

Issue 2: performance.  Until someone fixes it (which is probably
hard), turning this thing on hurts a lot.  Oleg added a hack awhile
ago that lets you do 'auditctl -a task,never' to get rid of the
performance hit for new tasks, but that rather defeats the point.

The scariness of the code can be lived with, but holy cow it's scary.

I'm just not going to fix the issues myself.  I tried and gave up.

--Andy
--
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/