These are sufficiently intertwined that they need to be done together.
riscv64 is our first primary-only architecture, so that required some
changes. The .bp changes are to support this --- we need to only show
the python scripts the architectures they'll actually be using, rather
than showing them everything and ignoring some of the results.
riscv64 is also the first architecture that post-dates the kernel's
64-bit time work, so there's a bit of extra fiddling needed to handle
the __NR3264_ indirection in the uapi headers.
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: local builds for x86-64 and riscv64
Change-Id: I74044744e80b312088f805c44fbd667c9bfcdc69
blacklist and whitelist are replaced with blocklist and allowlist
respectively.
Test: CtsSeccompHostTestCases
Change-Id: I39d9eda89038d1addbdaed59284a254a34cea1c6
Add a new function that installs a seccomp filter that checks
all setresuid/setresgid syscalls to fall within the passed in
uid/gid range. It allows all other syscalls through. Therefore,
this filter is meant to be used in addition to one of the
regular whitelist syscall filters. (If multiple seccomp filters
are installed a in process, all filters are run, and the most
restrictive result is used).
Since the regular app and app_zygote seccomp filters block all
other calls to change uid/gid (setuid, setgid, setgroups,
setreuid, setregid, setfsuid), combining these filters prevents
the process from using any other uid/gid than the one passed as
arguments to the new function.
Bug: 111434506
Test: atest CtsSeccompHostTestCases
Change-Id: If330efdafbedd8e7d38ca81896a4dbb0bc49f431
The APP_ZYGOTE seccomp policy is identical to the APP seccomp policy,
with the exception of allowing setresgid(32), which the app zygote
needs to be able to do (within a certain range).
Bug: 111434506
Test: manual
Change-Id: I34864837c981d201225e3e2e5501c0415a9a7dc8
Bionic maps typical C functions like setresuid() to a syscall,
depending on the architecture used. This tool generates a .h
file that maps all bionic functions in SYSCALLS.txt to the
syscall number used on a particular architecture. It can then
be used to generate correct seccomp policy at runtime.
Example output in func_to_syscall_nrs.h:
Bug: 111434506
Test: manually inspect func_to_syscall_nrs.h
Change-Id: I8bc5c1cb17a2e7b5c534b2e0496411f2d419ad86
This change avoids having to run the genseccomp.py script every time a
policy file is edited, and instead generates these files at
compile-time.
Bug: None
Test: m
Test: find out/soong/ -name x86_64_global_policy.cpp # Shows files
Test: generated policies are equivalent to original policies
Change-Id: I12461fe0c5fb02c008c1b2503fbb994b8aa2f56b
This change allows the use of readlink(2) so that UBSan can work
correctly on x86_64.
Bug: 111999822
Test: CtsWrapWrapDebugTestCases
Change-Id: I7f3013c712e3e41567a0d8e1bbb9d378c04b4433
This reverts commit 040c28a023.
Reason for revert: reland since the actual problem has been fixed
Change-Id: Ifd8a85b0de2eb6f2a76a6458570fc03b020a90ab
Test: the apps in the bug no longer crashes.
Bug: 76461821
Several privileged syscalls are still needed before a zygote-fork hangs
over the execution to the apps.
Test: system starts, different apps run
Bug: 63944145
Bug: 76461821
Change-Id: I78da54dac509eb073bc2aa7b820a1f6b0c39a775
521b41 "Allow system processes to use vfork"
ed74ab "Move some syscalls in commmon whitelist to app"
An implementation bug actually assigns the system seccomp filter to all
processes after zygote forks.
Test: the apps in the bug no longer crashes.
Bug: 76461821
java.lang.ProcessBuilder is internally using vfork in the current
configuration (see UNIXProcess_md.c in libcore).
Test: On an x86 Chromebook, trigger dropbox error event (1. settings
put global logcat_for_system_app_anr 50; 2. kill -19 `pidof
com.android.settings'; touch Settings). Saw seccomp error in
logcat but only without this fix.
Test: fyi, not reproducible on walleye (arm64)
Bug: 74441404
Change-Id: I1f40ae0fe0607c5834ecbe040ed31c4c0e42131d
We've been using #pragma once for new internal files, but let's be more bold.
Bug: N/A
Test: builds
Change-Id: I7e2ee2730043bd884f9571cdbd8b524043030c07
The netd service and system server will use bpf syscalls to get network
stats information when kernel supported. And the syscall from system
server will need seccomp permission to run it.
Test: -m CtsNetTestCases -t android.net.cts.TrafficStatsTest
Bug: 30950746
Change-Id: I01c46f243dca0933a44cbfd3148f9e4748f9bc99
Setting PR_SET_NO_NEW_PRIVS actually breaks SELinux domain transition
(of debuggerd, for example). Do not set the bit when install the filter.
Instead, the caller must either have done it, or have CAP_SYS_ADMIN.
Test: build
Bug: 63944145
Bug: 71859146
Change-Id: I2af334fed61cac03fd0b3b5c8866e2e72b31cf17
To pave the way to reducing app's kernel attack surface, this change
split the single filter into one for system and one for apps. Note that
there is current no change between them.
Zygote will apply these filters appropriately to system server and apps.
Keep set_seccomp_filter() for now until the caller has switched to the
new API, which I will do immediately after this before the two filters
diverse.
Also remove get_seccomp_filter() since it doesn't seem to be used
anyway.
Test: diff the generated code, no difference except the variable names
Test: cts -m CtsSecurityTestCases -t android.security.cts.SeccompTest
Bug: 63944145
Change-Id: Id8ba05a87332c92ec697926af77bc5742eb04b23
Enabling seccomp across all processes, rather than just zygote, is
useful for auditing the syscall usage of AOSP. Create a global seccomp
policy that can optionally be enabled by init.
Bug: 37960259
Test: confirm global seccomp by removing finit_module from policy and
observing modprobe fail, confirm regular seccomp unchanged by
comparing length of installed bpf
Change-Id: Iac53a42fa26a80b05126f262dd9525f4f66df558
This seccomp failure is in the fault handler:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : backtrace:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : #00 pc 00015380
/data/data/redacted/files/storage/lib/libcrashsdk.so
So whenever an app using this crash sdk crashes it looks like a seccomp
problem. Fixing this won't stop the apps crashing, but will make the
crash reports accurate and useful.
So yes, the bug below is already fixed, but this issue has come back 2
or 3 times with different apps (latest is b/62874867). This change
doesn't fix that crash either, but again it improves the reporting.
Bug: 62090571
Test: Device boots, app still fails but no longer with SECCOMP error
Change-Id: Ie0f8dc965001c8bc43f6a545b35bdcd38f006213
Set correct values for PRIMARY and SECONDARY arch definitions
to match LE MIPS architectures.
This change is resolving boot problem for mips32 arch with 3.18 kernel.
This also fixes mips64 issue related to PRIMARY_ARCH definition,
but in order to boot to home screen it needs additional syscalls whitelisted
which will be introduced in separate patch.
Tested on emulator:
emulator -kernel prebuilts/qemu-kernel/mips/3.18/kernel-qemu2
Change-Id: I68dfd136c22141933a8a8c5336db01a02f00b0df
Add some useful new syscalls that we currently aren't using in bionic,
but might in the future to the seccomp whitelist.
Bug: http://b/37317198
Test: mma
Change-Id: I6550867da152cea84fb13d0c15a399cdb2acf1aa
Bug: 37253880
Test: Make sure device boots
Run pylint on genseccomp.py, test_genseccomp.py
Run test_genseccomp.py
Run new CTS test
cts-tradefed run cts -m CtsSecurityTestCases -t android.security.cts.SeccompTest
Change-Id: I833a5364a1481d65173e77654da1798dc45a3f9d
The check that we are not below the lowest permitted syscall was
off by one, so we always allowed them, rather than always denying
them
Test: Check arm64 boots, chrome and maps work
mips and mips64 emulators boot
Note that arm, x86 and x86_64 already allow syscall 0 so there
will be no functional change there
Change-Id: I85873f1d04124e634e648bd47c027f280f1d6dbd
Test: Make sure arm, x86, x86_64, mips, mips64 emulators boot
Make sure sailfish still boots
Ran CTS test from
https://android-review.googlesource.com/#/c/348671/3 and it passed
The instructions for how to run mips emulators above worked, but
the CTS tests did not seem to actually run.
Change-Id: Iddee5acdb19ed32c7bd4657573313ca439cf6a49
