linux-kernel - Re: [PATCH v2.1] audit: Only use the syscall slowpath when syscall audit rules exist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrWx2eQOyVXD-2xVCac4RYSu1toLG=Rd4fhpXTi+T0XkWA@mail.gmail.com>
Date:	Mon, 3 Feb 2014 13:09:54 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-audit@...hat.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Steve Grubb <sgrubb@...hat.com>
Subject: Re: [PATCH v2.1] audit: Only use the syscall slowpath when syscall
 audit rules exist

On Mon, Feb 3, 2014 at 12:35 PM, Eric Paris <eparis@...hat.com> wrote:
> Hmmmm,
>
> My problem with doing this has always actually been because of SELinux.
> Knowing syscall information with AVCs can be a huge help running down
> problems.  We already make people load rules if they want to get
> pathname type records, so maybe this is fine.  Or we could make SELinux
> take a reference on the number of audit rules, but that was your
> particular use case.  Not sure how I feel about losing syscall
> information by default on AVCs...
>

Hmm.  I never noticed that feature.  That'll show me :)

I would personally happily give that up for a 30-50% reduction in
systemwide syscall latency.

Looking at the 64-bit syscall entry code, it looks like the syscall nr
is always saved to pt_regs (as orig_rax) and the arguments are shoved
into the usual places in pt_regs.  Have you ever tried using
syscall_get_nr and syscall_get_arguments from the audit code without
setting TIF_SYSCALL_AUDIT?  I may be missing something here, but it
looks like it'll work.

> Do we always have audit_context allocated?  I need to look how the TIF
> and audit_context are correlated.

In 3.13, TIF_SYSCALL_AUDIT is set iff audit_context is allocated.  In
3.12 and below that was not the case due to a bug.

>
> For a completely seperate non-audit patch idea I've toyed with making
> the arch/syscall_nr a0,a1,a2,a3 stored in task struct rather than audit
> context.  Would mean that recording that information on syscall entry
> could be fast/easy and done quickly in syscall entry assembly code.
> Then on entry we could track only if there are rules on the 'entry' list
> and skip if none.  On exit we could do the same only with exit rules.
> Right now all 3 of those different things are tracked in
> TIF_SYSCALL_AUDIT (As I recall the slow path is usually a lot of things
> other than audit, but audit is what forces us onto the slow patch)

I think that you can already fish out the syscall args on x86_64 at
least.  The attached awful patch appears to work, for example.

Test code:

#include <stdio.h>
#include <linux/prctl.h>

int main(int argc, char **argv)
{
  if (argc != 5) {
    printf("Usage: test_pr500 arg2 arg3 arg4 arg5\n");
    return 1;
  }

  prctl(500, atoi(argv[1]), atoi(argv[2]), atoi(argv[3]), atoi(argv[4]));
  return 0;
}

FWIW, I don't know *why* the syscall fast path does this, but it's
convenient for this use :)

Out of curiosity, why does the audit code ignore a4 and a5?

--Andy

View attachment "awful_syscall_hack.patch" of type "text/x-patch" (810 bytes)