Interesting. Since this one just started failing recently you should try a bisect, e.g.:

cbuildot --remote amd64-generic-tot-asan-informational --chrome_revision 225f8d7c

Er...

cbuildbot --remote amd64-generic-tot-asan-informational --chrome_revision 225f8d7c

See also https://yaqs.googleplex.com/eng/q/5279836254240768

Just did a manual bisect, and it seems this is the culprit CL:
https://chromium.googlesource.com/chromium/src/+/4fa5f3285b050cb2823b41320777cb52f64c9508

vasilii@, could you take a look at this? 

Actually the earliest builder that failed the sandbox service is #10838: 
https://build.chromium.org/p/chromiumos.chromium/builders/amd64-generic-tot-asan-informational/builds/10838 

The code path I changed wasn't executed by the test for sure. Out of 26 possible culprits those two look more noticeable:
- https://chromiumcodereview.appspot.com/2352353002
- https://chromiumcodereview.appspot.com/2430593002

Assigning to jamescook@ for analysis as he was involved in both of them.

To lhchavez, cc cychiang

This doesn't look like a Chrome problem to me. It looks like the test is checking seccomp permissions for system daemons mtpd (media transport protocol daemon) and netfilter-queue (networking daemon of some sort).

Suspecting either of these changes:
minijail: Use the AOSP commit and tree hashes
https://chromium-review.googlesource.com/#/c/399891/

security_SandboxedServices: Add minijail-init to baseline
https://chromium-review.googlesource.com/#/c/400203/

Here's the actual error:
08:37:33.912 ERROR|security_Sandboxed:0259| mtpd: missing seccomp usage: wanted 2 (filter) but got 0 (disabled)
08:37:33.915 ERROR|security_Sandboxed:0259| netfilter-queue: missing seccomp usage: wanted 2 (filter) but got 0 (disabled)
08:37:33.917 WARNI|security_Sandboxed:0266| Stale baselines: set(['# Since udev creates device nodes and changes owners/perms', 'attestationd', '# launch new shells via login.  Would be nice if it integrated things.', '# Frecon needs to run as root and in the original namespace because it might', 'timberslide', '# We need to run as root due to caps not preserving across execs.', 'brcm_patchram_p', 'arc-obb-mounter', 'thermal.sh', '# firewalld will fork+exec iptables to handle requests', 'easy_unlock', 'wimax-manager', 'daisydog', 'tcsd', 'sslh-fork', 'X', '# Broadcomm bluetooth firmware patch downloader runs on some veyron boards.', '# takes care of dropping root/caps for those commands.', '# TODO: We can fix this when minijail supports ambient caps.  http://b/32066154', '# root.  TODO: We should namespace it.', 'cromo', 'esif_ufd', 'arc-networkd', 'minijail-init', 'lid_touchpad_he'])
08:37:33.919 WARNI|security_Sandboxed:0269| New services: set(['webservd', 'buffet', 'apmanager', 'peerd', 'nacl_helper_non', 'avahi-daemon'])
08:37:33.922 ERROR|security_Sandboxed:0284| Failed sandboxing: ['mtpd', 'netfilter-queue']
08:37:33.928 WARNI|              test:0606| Autotest caught exception when running test:
Traceback (most recent call last):
  File "/usr/local/autotest/common_lib/test.py", line 600, in _exec
    _call_test_function(self.execute, *p_args, **p_dargs)
  File "/usr/local/autotest/common_lib/test.py", line 804, in _call_test_function
    return func(*args, **dargs)
  File "/usr/local/autotest/common_lib/test.py", line 461, in execute
    dargs)
  File "/usr/local/autotest/common_lib/test.py", line 347, in _call_run_once_with_retry
    postprocess_profiled_run, args, dargs)
  File "/usr/local/autotest/common_lib/test.py", line 376, in _call_run_once
    self.run_once(*args, **dargs)
  File "/usr/local/autotest/tests/security_SandboxedServices/security_SandboxedServices.py", line 285, in run_once
    raise error.TestFail("One or more processes failed sandboxing")
TestFail: One or more processes failed sandboxing
08:37:34.591 ERROR|          parallel:0026| child process failed

Huh, so all the processes that expect to have a seccomp filter don't have them? I don't think https://chromium-review.googlesource.com/#/c/400203/ is the culprit, so https://chromium-review.googlesource.com/#/c/399891/ seems to be the only one left out.

jorgelo@ can you think of anything that would have changed that behavior?

This is the ASan builder -- Minijail will not enable seccomp on ASan because ASan uses extra syscalls: https://cs.corp.google.com/android/external/minijail/libminijail.c?q=minijail.c+package:%5Eandroid$&l=1477

The test needs to be updated to not fail if running with ASan. Over to Mike.

FWIW there was an ASan-related change in that range: we switched from checking for ASan at compile-time vs run-time -- that's probably what's causing the test to fail now and not before.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/3ff916407d256c146c8157b297b59b6085243502

commit 3ff916407d256c146c8157b297b59b6085243502
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Oct 26 04:27:17 2016

security_SandboxedServices: skip seccomp checks on asan images

Since minijail will disable seccomp usage when asan is active, there's
no value in enforcing runtime checks on that field.  Silently skip it.

BUG= chromium:658777 
TEST=precq passes
TEST=amd64-generic-asam bot passes

Change-Id: I1d877703277ccec13e301f0d6dfcc41402055ec1
Reviewed-on: https://chromium-review.googlesource.com/403648
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/3ff916407d256c146c8157b297b59b6085243502/client/site_tests/security_SandboxedServices/security_SandboxedServices.py

Closing. Please reopen it if its not fixed. Thanks!