1465152 - Sandbox on Linux floods audit logs with SECCOMP events

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect, P5)

Description

[Steve]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180523133746

Steps to reproduce:

If you are on a Linux system with auditing enabled, you get thousands of SECCOMP audit events. This is flooding the logs and making it hard to keep logs that span a month due to sheer volume of events. Note, this problem has been going on for months. It was originally reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=1507282

To reproduce, you need to have auditing enabled. Then start visiting web sites with Firefox.


Actual results:

To see how many events I have this month:

# ausearch --start this-month --raw -x firefox | aureport --event --summary -i

Event Summary Report
======================
total  type
======================
2728842  SECCOMP
634  SYSCALL

That's over 2 million! To see what syscalls the sandbox is trapping:

# ausearch --start this-month --raw -x firefox -m seccomp | aureport --syscall --summary -i

Syscall Summary Report
==========================
total  syscall
==========================
953993  stat
945334  openat
821814  unlink
4806  access
2130  readlink
272  open
246  mkdir
98  statfs
87  socket
86  connect
35  socketpair
8  chmod
7  ioctl
4  lstat

I suspect these should be allowed. But let's look at an event:

# ausearch --start today -m seccomp -x firefox -i --just-one
----
node=x2 type=SECCOMP msg=audit(05/29/2018 07:03:13.423:695) : auid=sgrubb uid=sgrubb gid=sgrubb ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=10270 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=openat compat=0 ip=0x7f01bd28149e code=trap 

They are all trap events. Trap events are for debugging and creates audit events. If the syscall was allowed in the seccomp filter, then we would not be getting events.


Expected results:

It should not be creating SECCOMP events. An occasional event showing a policy violation is OK. These are not policy violations.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

SECCOMP_RET_TRAP is being used for exactly what its author proposed when it was committed[*]: “in-process system call emulation”.

Specifically, in most of these cases it's being used to emulate syscalls that take filesystem paths by messaging an out-of-process broker which can filter based on the string contents, because seccomp-bpf itself can't do that.  (The ioctl traps are an exception; those shouldn't be happening.  If you can reproduce whatever happened there with MOZ_SANDBOX_CRASH_ON_ERROR=1 set in the environment, it should generate a crash report.)

I suggest not trying to treat SECCOMP_RET_TRAP as an exceptional situation.  If that's not feasible, is there some way you can exclude Firefox's seccomp-bpf policy from this logging that you're doing?


[*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb6ea4301a1109afdacaee576fedbfcd7152fc86

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

This isn't something we can fix on our end.