seccomp and audit_enabled

Mon Oct 12 20:45:38 UTC 2015

On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones <tonyj at suse.de> wrote:
> On 10/12/2015 08:40 AM, Paul Moore wrote:
>> My apologies for the resend, I had the wrong email for Kees.

(I keep asking for that alias, but no luck...)

>> On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
>>> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
>>>> Hi.
>>>>
>>>> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
>>>> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
>>>> auditd is running) there is a lot of messages dumped to the klog. The fix
>>>> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
>>>> patch, I'm just not sure if seccomp is somehow special?
>>>
>>> I'm adding Kees to this since he looks after the seccomp kernel bits these
>>> days.  While there isn't anything special about seccomp from an audit
>>> perspective, the seccomp audit record can be a really nice thing as it is
>>> the only indication you may get that seccomp has stepped in and done
>>> "something" other than allow the syscall to progress normally.
>
> The issue is that (without auditd running) the messages are output to klog regardless
> of whether audit_enabled is 0 or 1.  As I said, other occurrences of this such as with
> login events has been corrected (c2412d91c). Attached patch does same for seccomp.
>
>>> I would be a little more concerned that you are seeing a flood of seccomp
>>> messages from Opera, that is something that most likely warrants some closer
>>> inspection.  Are all the records the same/similar?  Can you paste some into
>>> email?
>
> Here is the logged messages per invocation of opera.  the use of the sandbox may well
> be the result of a local suse config/packaging decision but I'm not sure that's relevant.
>
> 2015-10-10T19:35:23.237882-07:00 nohostname kernel: [  152.100348] audit: type=1326 audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000
> 2015-10-10T19:35:23.242867-07:00 nohostname kernel: [  152.105690] audit: type=1326 audit(1444530923.241:357): auid=1000 uid=1000 gid=100 ses=1 pid=2087 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
> 2015-10-10T19:35:23.242873-07:00 nohostname kernel: [  152.105938] audit: type=1326 audit(1444530923.241:358): auid=1000 uid=1000 gid=100 ses=1 pid=2089 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
> 2015-10-10T19:35:23.243890-07:00 nohostname kernel: [  152.106845] audit: type=1326 audit(1444530923.242:359): auid=1000 uid=1000 gid=100 ses=1 pid=2048 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7ff926d6daa1 code=0x30000
> 2015-10-10T19:35:23.275872-07:00 nohostname kernel: [  152.138819] audit: type=1326 audit(1444530923.273:360): auid=1000 uid=1000 gid=100 ses=1 pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
> 2015-10-10T19:35:23.275885-07:00 nohostname kernel: [  152.138937] audit: type=1326 audit(1444530923.274:361): auid=1000 uid=1000 gid=100 ses=1 pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
> 2015-10-10T19:35:23.280867-07:00 nohostname kernel: [  152.143147] audit: type=1326 audit(1444530923.279:362): auid=1000 uid=1000 gid=100 ses=1 pid=2096 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7f92e6168444 code=0x50000
> 2015-10-10T19:35:23.282055-07:00 nohostname kernel: [  152.144762] audit: type=1326 audit(1444530923.280:363): auid=1000 uid=1000 gid=100 ses=1 pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f92eb5f8587 code=0x50000
> 2015-10-10T19:35:23.282062-07:00 nohostname kernel: [  152.144890] audit: type=1326 audit(1444530923.280:364): auid=1000 uid=1000 gid=100 ses=1 pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f92e4b2ac8c code=0x50000
> 2015-10-10T19:35:23.282063-07:00 nohostname kernel: [  152.144988] audit: type=1326 audit(1444530923.280:365): auid=1000 uid=1000 gid=100 ses=1 pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f92e4b2ad70 code=0x50000
>
>
> thanks
>
> tony
>
>
> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
> From: Tony Jones <tonyj at suse.de>
> Date: Sat, 10 Oct 2015 19:30:49 -0700
> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>
> Don't log seccomp messages when audit is disabled.

This is intentional since violation of a seccomp policy ought to
indicate a misbehaving program, and we want these to always be
presented to the system log, regardless of audit being enabled. (I'd
like to even produce system log entries when there is no CONFIG_AUDIT
too, but that's for the future.)

> Currently, each time the opera browser is executed 10 records similar to the
> following are output to klog (when !audit_enabled).
>
> 2015-10-10T19:35:23.237882-07:00 nohostname kernel: [  152.100348] audit: type=1326 audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000

However, these are all sig=0, which would indicate a skipped syscall,
which I wouldn't expect to get reported at all.

>
> Signed-off-by: Tony Jones <tonyj at suse.de>
> ---
>  include/linux/audit.h | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b2abc99..8f70f3f 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -113,6 +113,12 @@ struct filename;
>
>  extern void audit_log_session_info(struct audit_buffer *ab);
>
> +#ifdef CONFIG_AUDIT
> +extern u32 audit_enabled;
> +#else
> +#define audit_enabled 0
> +#endif
> +
>  #ifdef CONFIG_AUDIT_COMPAT_GENERIC
>  #define audit_is_compat(arch)  (!((arch) & __AUDIT_ARCH_64BIT))
>  #else
> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
>  static inline void audit_seccomp(unsigned long syscall, long signr, int code)
>  {
>         /* Force a record to be reported if a signal was delivered. */
> -       if (signr || unlikely(!audit_dummy_context()))

What is dummy_context part of this actually do? I don't think reports
should be made when signr == 0.

-Kees

> +       if (audit_enabled && (signr || unlikely(!audit_dummy_context())))
>                 __audit_seccomp(syscall, signr, code);
>  }
>
> @@ -498,7 +504,6 @@ extern int audit_rule_change(int type, __u32 portid, int seq,
>                                 void *data, size_t datasz);
>  extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
>
> -extern u32 audit_enabled;
>  #else /* CONFIG_AUDIT */
>  static inline __printf(4, 5)
>  void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
> @@ -544,7 +549,6 @@ static inline int audit_log_task_context(struct audit_buffer *ab)
>  static inline void audit_log_task_info(struct audit_buffer *ab,
>                                        struct task_struct *tsk)
>  { }
> -#define audit_enabled 0
>  #endif /* CONFIG_AUDIT */
>  static inline void audit_log_string(struct audit_buffer *ab, const char *buf)
>  {
> --
> 2.1.4
>
>
>

-- 
Kees Cook
Chrome OS Security