Why is syscall auditing on with no rules?

Why is syscall auditing on with no rules?

[Andy Lutomirski]

On a stock Fedora installation:

$ sudo auditctl -l
No rules

Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and
__audit_syscall_exit account for >20% of syscall overhead according to
perf.

This sucks.  Unless I'm missing something, syscall auditing is *off*.

How hard would it be to arrange for TIF_SYSCALL_AUDIT to be cleared
when there are no syscall rules?

(This is extra bad in kernels before 3.13, where the clear call for
TIF_SYSCALL_AUDIT was completely missing.)

--Andy

Re: Why is syscall auditing on with no rules?

[Andy Lutomirski]

On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On a stock Fedora installation:
>
> $ sudo auditctl -l
> No rules
>
> Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and
> __audit_syscall_exit account for >20% of syscall overhead according to
> perf.
>
> This sucks.  Unless I'm missing something, syscall auditing is *off*.
>
> How hard would it be to arrange for TIF_SYSCALL_AUDIT to be cleared
> when there are no syscall rules?
>
> (This is extra bad in kernels before 3.13, where the clear call for
> TIF_SYSCALL_AUDIT was completely missing.)

The current code seems to have really odd effects.  For example,
processes that are created before the very first auditctl -e 1 (or
auditd) invocation will never be subject to syscall auditing.  But
auditctl -e 1; auditctl -e 0 will cause all subsequently started
processes to have audit contexts allocated and therefore to be subject
to syscall auditing.

I doubt that this behavior is considered desirable.

--Andy

>
> --Andy



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: Why is syscall auditing on with no rules?

[Andi Kleen]

Andy Lutomirski <luto@amacapital.net> writes:

> On a stock Fedora installation:
>
> $ sudo auditctl -l
> No rules

I noticed the same recently on a recent opensuse. kauditd is running,
even though I uninstalled all audit related userland long before. I'm sure
the evil "make syscalls slow" flag is set too.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

Re: Why is syscall auditing on with no rules?

[Steve Grubb]

On Saturday, February 01, 2014 06:51:56 PM Andy Lutomirski wrote:
> On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On a stock Fedora installation:
> > 
> > $ sudo auditctl -l
> > No rules

What rules would you want? The audit package ships with several which affects 
performance to varying degrees. The default one affects it the least. If you 
don't want auditing, don't install the audit package.


> > Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and
> > __audit_syscall_exit account for >20% of syscall overhead according to
> > perf.
> > 
> > This sucks.  Unless I'm missing something, syscall auditing is *off*.

The audit daemon enables auditing unless you add -s=nochange to the daemon's 
commandline parameters. The rules are loaded by a separate process so the 
deamon just enables auditing so that any selinux AVCs have more information 
and in case auditctl loads rules. If you don't want auditing, simply don't 
install it and things will be OK.


> > How hard would it be to arrange for TIF_SYSCALL_AUDIT to be cleared
> > when there are no syscall rules?

This only gets set if auditing is enabled. What if in the future someone loads 
rules? For example, what if you reload audit rules? The first thing that 
happens is it clears any previous rules. If we did what you suggested, then 
any process that runs between the time the rules were deleted and a rule gets 
loaded will never be auditable. We can't have that. Sometimes admins stop the 
audit daemon to do some looking around. Usually audit rules are cleared when 
its stopped. Once again you have a window where processes will become 
inauditable. 

We take the point of view that if you want auditing and all that it brings 
with it, this will be setup by the audit daemon. If you want no auditing and 
no performance hit, simply don't install it or disable it from starting and 
all will be fine.


> > (This is extra bad in kernels before 3.13, where the clear call for
> > TIF_SYSCALL_AUDIT was completely missing.)
> 
> The current code seems to have really odd effects.  For example,
> processes that are created before the very first auditctl -e 1 (or
> auditd) invocation will never be subject to syscall auditing.

This is correct. Its also why we have a audit=1 boot command. Anyone needing 
audit must have that boot configuration or they will have inauditable 
processes. This is documented in the auditd man page.


> But auditctl -e 1; auditctl -e 0 will cause all subsequently started
> processes to have audit contexts allocated and therefore to be subject
> to syscall auditing.
> 
> I doubt that this behavior is considered desirable.

What you are describing is the compromise between no performance hit and 
auditing. If you want it to work right, you have to set it up right. The 
audit=1 commandline prompt is in security docs like the NSA SNAC guide and 
encoded into security scanners that process STIG or USGCB content. I also 
believe its mentioned in Common criteria docs that any distribution that has 
been certified publishes.

HTH...

-Steve

Re: Why is syscall auditing on with no rules?

[Andy Lutomirski]

On Mon, Feb 3, 2014 at 6:49 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Saturday, February 01, 2014 06:51:56 PM Andy Lutomirski wrote:
>> On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > On a stock Fedora installation:
>> >
>> > $ sudo auditctl -l
>> > No rules
>
> What rules would you want? The audit package ships with several which affects
> performance to varying degrees. The default one affects it the least. If you
> don't want auditing, don't install the audit package.

Actually, 'task,never' is lower overhead on 3.13, but I'm fine with
"No rules".  However...

>> > How hard would it be to arrange for TIF_SYSCALL_AUDIT to be cleared
>> > when there are no syscall rules?
>
> This only gets set if auditing is enabled. What if in the future someone loads
> rules? For example, what if you reload audit rules? The first thing that
> happens is it clears any previous rules. If we did what you suggested, then
> any process that runs between the time the rules were deleted and a rule gets
> loaded will never be auditable. We can't have that. Sometimes admins stop the
> audit daemon to do some looking around. Usually audit rules are cleared when
> its stopped. Once again you have a window where processes will become
> inauditable.
>
> We take the point of view that if you want auditing and all that it brings
> with it, this will be setup by the audit daemon. If you want no auditing and
> no performance hit, simply don't install it or disable it from starting and
> all will be fine.

I actually do want auditing -- I need it if I want to see AVC denials.
 But I don't want syscall auditing, nor do most people, which is
entirely consistent with the default rules.

It's permissible to set and clear TIF_SYSCALL_AUDIT from a different
thread.  Given that changing the list of syscall audit rules is
probably *much* rarer than calling a syscall and that
TIF_SYSCALL_AUDIT appears to more than double total syscall latency on
Sandy Bridge (and it quite possible even worse on newer hardware), it
seems to me that a much better solution would be to dynamically turn
TIF_SYSCALL_AUDIT on and off.

I wouldn't hesitate to implement this, except that I'm a bit scared of
the code.  (e.g. why is audit_context in task_struct still there even
if syscsall auditing is configured out.  What happens if a task enters
a syscall w/ TIF_SYSCALL_AUDIT clear and returns with it set or vice
versa?)

I'd go even farther and allow auditing to be globally turned on after
processes are created (removing the need for audit=1 or whatever), but
that would require a lot more familiarity with the code.

--Andy