Introduce isolated_app_all typeattribute to share policies between
isolated_app and future similar apps that wish to be enforced with
isolation properties.
Bug: 255597123
Test: m && presubmit
Change-Id: I0d53816f71e7d7a91cc379bcba796ba65a197c89
Brings in the io_uring class and associated restrictions and adds a new
macro, `io_uring_use`, to sepolicy.
In more detail, this change:
* Adds a new macro expands to ensure the domain it is passed can undergo a
type transition to a new type, `<domain>_iouring`, when the anon_inode
being accessed is labeled `[io_uring]`. It also allows the domain to
create, read, write, and map the io_uring anon_inode.
* Adds the ability for a domain to use the `IORING_SETUP_SQPOLL` flag
during `io_uring_setup` so that a syscall to `io_uring_enter` is not
required by the caller each time it wishes to submit IO. This can be
enabled securely as long as we don't enable sharing of io_uring file
descriptors across domains. The kernel polling thread created by `SQPOLL`
will inherit the credentials of the thread that created the io_uring [1].
* Removes the selinux policy that restricted all domains that make use of
the `userfault_fd` macro from any `anon_inode` created by another domain.
This is overly restrictive, as it prohibits the use of two different
`anon_inode` use cases in a single domain e.g. userfaultfd and io_uring.
This change also replaces existing sepolicy in fastbootd and snapuserd
that enabled the use of io_uring.
[1] https://patchwork.kernel.org/project/linux-security-module/patch/163159041500.470089.11310853524829799938.stgit@olly/
Bug: 253385258
Test: m selinux_policy
Test: cd external/liburing; mm; atest liburing_test; # requires WIP CL ag/20291423
Test: Manually deliver OTAs (built with m dist) to a recent Pixel device
and ensure snapuserd functions correctly (no io_uring failures)
Change-Id: I96f38760b3df64a1d33dcd6e5905445ccb125d3f
Split virtualizationservice policy into rules that should remain with
the global service and rules that now apply to virtmgr - a child process
of the client that runs the VM on its behalf.
The virtualizationservice domain remains responsible for:
* allocating CIDs (access to props)
* creating temporary VM directories (virtualization_data_file, chown)
* receiving tombstones from VMs
* pushing atoms to statsd
* removing memlock rlimit from virtmgr
The new virtualizationmanager domain becomes responsible for:
* executing crosvm
* creating vsock connections, handling callbacks
* preparing APEXes
* pushing ramdumps to tombstoned
* collecting stats for telemetry atoms
The `virtualizationservice_use` macro is changed to allow client domains
to transition to the virtmgr domain upon executing it as their child,
and to allow communication over UDS.
Clients are not allowed to communicate with virtualizationservice via
Binder, only virtmgr is now allowed to do that.
Bug: 250685929
Test: atest -p packages/modules/Virtualization:avf-presubmit
Change-Id: Iefdccd908fc28e5d8c6f4566290e79ed88ade70b
Start a new security domain for virtmgr - a child proces of an app that
manages its virtual machines.
Add permissions to auto-transition to the virtmgr domain when the client
fork/execs virtmgr and to communicate over UDS and pipe.
Bug: 250685929
Test: atest -p packages/modules/Virtualization:avf-presubmit
Change-Id: I7624700b263f49264812e9bca6b83a003cc929be
While running the MicrodroidTests I noticed denials like these:
avc: denied { getattr } for comm="virtualizations" path="pipe:[86794]"
dev="pipefs" ino=86794 scontext=u:r:virtualizationservice:s0
tcontext=u:r:untrusted_app:s0:c122,c256,c512,c768 tclass=fifo_file
permissive=0
These are harmless, so we could dontaudit them, but it is also fine
to simply allow getattr.
Test: atest MicrodroidTests, no denials seen
Change-Id: I53a2967eb6e396979a86715b3d5a7681f48dcb63
VintfObject will monitor for /apex directory for VINTF data.
Add permissions for service managers to read this data.
Bug: 239055387
Test: m && boot
Change-Id: I179e008dadfcb323cde58a8a460bcfa2825a7b4f
When a kernel panic occurs in a debug-enabled VM, a crashdump is created
in the VM and then it is flushed to the per-VM host-side file
/data/misc/virtualizationservice/<cid>/ramdump. Virtualizationservice
then opens the file and sends the FD to the owning client. This change
allows the client to read the ramdump via the FD.
A client accessing ramdump of other VM is prohibited since opening the
ramdump file is not allowed for the client; only virtualizationservice
can do it. Furthermore, ramdumping will be enabled only for the
debuggable VMs, which means reading it doesn't actually reveal any
(true) secret.
Bug: 238278104
Test: do the ramdump
Change-Id: I50e1fa83b99e8f24c849e278710b38f6ff9a25be
Relevant error logs show up when dumpstate do lsof using su identity:
RunCommand("LIST OF OPEN FILES", {"lsof"}, CommandOptions::AS_ROOT);
This is an intended behavior and the log is useless for debugging so I
suppress them.
Bug: 226717429
Test: do bugreport with relevant error gone.
Change-Id: Ide03315c1189ae2cbfe919566e6b97341c5991bb
Any virtualization service client should be able to use a pipe for the
VM log fds.
We previously had some support for this in crosvm (but appdomain is
the wrong label), but not for virtualizationservice. Instead I've
centralised it in the virtualizationservice_use macro so it applies to
exactly those things that can start a VM.
I've removed read permission from crosvm; it doesn't seem to be
needed, and logically it shouldn't be.
Test: Patch in https://r.android.com/1997004, see no denials
Change-Id: Ia9cff469c552dd297ed02932e9e91a5a8cc2c13f
Clients of virtualization service use these properties to
determine whether normal and protected VMs are supported and tailor
their VM requests accordingly.
Bug: 217687661
Test: adb unroot; adb shell getprop | grep ro.boot.hypervisor
Change-Id: Ia1c017c2346217dbc45973cbfb5adbecabedf050
fs_mgr::ReadDefaultFstab calls fs_mgr:ReadFstabFromDt() which eventually
calls fs_mgr_get_boot_config_from_bootconfig_source to read boot config.
Therefore bundle permission to read proc_bootconfig. This resolves some
selinux denials for update_engine
Test: th
Change-Id: Ia8bd94eb33a38ccd939577b54910645fec4ccda8
Remove some allow rules for odsign, since it no longer directly
modifies CompOs files. Instead allow it to run compos_verify_key in
its own domain.
Grant compos_verify_key what it needs to access the CompOs files and
start up the VM.
Currently we directly connect to the CompOs VM; that will change once
some in-flight CLs have landed.
As part of this I moved the virtualizationservice_use macro to
te_macros so I can use it here. I also expanded it to include
additional grants needed by any VM client that were previously done
for individual domains (and then deleted those rules as now
redundant).
I also removed the grant of VM access to all apps; instead we allow it
for untrusted apps, on userdebug or eng builds only. (Temporarily at
least.)
Bug: 193603140
Test: Manual - odsign successfully runs the VM at boot when needed.
Change-Id: I62f9ad8c7ea2fb9ef2d468331e26822d08e3c828
Revert submission 1668411
Reason for revert: Suspect for b/186173384
Reverted Changes:
Iaa4fce9f0:Check that tracefs files are labelled as tracefs_t...
I743a81489:Exclude vendor_modprobe from debugfs neverallow re...
I63a22402c:Add neverallows for debugfs access
I289f2d256:Add a neverallow for debugfs mounting
Change-Id: Ie04d7a4265ace43ba21a108af85f82ec137c6af0
Android R launching devices and newer must not ship with debugfs
mounted. For Android S launching devices and newer, debugfs must only be
mounted in userdebug/eng builds by init(for boot time initializations)
and dumpstate(for grabbing debug information from debugfs). This patch
adds a neverallow statement that prevents processes other than init
from being provided access to mount debugfs in non-user builds
when the flag PRODUCT_SET_DEBUGFS_RESTRICTIONS is set to true.
Test: make with/without PRODUCT_SET_DEBUGFS_RESTRICTIONS
Bug: 184381659
Change-Id: I289f2d25662a78678929e29f83cb31cebd8ca737
Split gsi_metadata_file into gsi_metadata_file plus
gsi_public_metadata_file, and add gsi_metadata_file_type attribute.
Files that are okay to be publicly readable are labeled with
gsi_public_metadata_file. Right now only files needed to infer the
device fstab belong to this label.
The difference between gsi_metadata_file and gsi_public_metadata_file is
that gsi_public_metadata_file has relaxed neverallow rules, so processes
who wish to read the fstab can add the respective allow rules to their
policy files.
Allow gsid to restorecon on gsi_metadata_file to fix the file context of
gsi_public_metadata_file.
Bug: 181110285
Test: Build pass
Test: Issue a DSU installation then verify no DSU related denials and
files under /metadata/gsi/ are labeled correctly.
Change-Id: I54a5fe734dd345e28fd8c0874d5fceaf80ab8c11
Some details here are copied from hal_attribute_hwservice but
no longer make sense here.
Bug: N/A
Test: N/A
Change-Id: Ia4a4d6731b5e5270922d32b7854d36bd726d202b
ART runtime will be using userfaultfd for a new heap compaction
algorithm. After enabling userfaultfd in android kernels (with SELinux
support), the feature needs policy that allows { create ioctl read }
operations on userfaultfd file descriptors.
Bug: 160737021
Test: Manually tested by exercising userfaultfd ops in ART
Change-Id: I9ccb7fa9c25f91915639302715f6197d42ef988e
To support multi-client resume on reboot, the recovery system
service want to query the active boot slot on the next boot; and
abort the reboot if the active slot is different from clients'
expectation.
Denial:
SELinux : avc: denied { find } for interface=android.hardware.boot::IBootControl
sid=u:r:system_server:s0 pid=1700 scontext=u:r:system_server:s0
tcontext=u:object_r:hal_bootctl_hwservice:s0 tclass=hwservice_manager permissive=1
Bug: 173808057
Test: adb shell cmd recovery reboot-and-apply ota reason
Change-Id: I6a303d8dcbae89a2287d96ae3116109e2a43bbd6
This simplifies operation by removing a special case for user builds.
Test: atest CtsPerfettoTestCases on user
Test: atest CtsPerfettoTestCases on userdebug
Test: atest perfetto_integrationtests on userdebug
Bug: 153139002
Change-Id: Ibbf3dd5e4f75c2a02d931f73b96fabb8157e0ebf
This is the service offered by Keystore 2.0 to provide APC service to
application. It was formerly part of the IKeystoreService interface.
Not it is an interface in ints own right.
Test: Keystore 2.0 can register the apc service interface.
Apps can lookup and call this interface.
Bug: 159341464
Change-Id: I058adf0021d9b89f4eac7534e366c29071f0f98b
Every property should have an appropriate owner attribute, which can be
one of: system_property_type, product_property_type, or
vendor_property_type. This will be enforced for devices launching with S
or later. Devices launching with R or eariler can relax this by setting
following under BoardConfig.mk:
BUILD_BROKEN_ENFORCE_SYSPROP_OWNER := true
Bug: 131162102
Test: system/sepolicy/tools/build_policies.sh
Change-Id: I7914ef1b7463c9ec00812b9720094531fd63f0c7
Like HIDL HALs, if we have a service which is allowed to access
hal_<foo>_service, we want that service to have the attribute
hal_<foo>_client.
Unlike HIDL HALs, some AIDL services are allowed to get ahold of all
HALs, so these have to be exempted from this check.
Fixes: 168152053
Test: neverallows pass
Change-Id: I4bce6d9441c2921c3ea40f2b01fef4030c02a28a
The previous attempt (aosp/1225417) had a missing piece: while we
allowed traced to use the shared memory, we haven't allowed it to use
the file descriptors in the producers' domains. Since the shared memory
is being transferred as an fd (obtained from memfd_create), the service
ends up hitting a denial (see below for an example).
We ended up missing the general case as we only tested with the shell
domain at the time, and traced is already allowed to use shell's fds for
other reasons.
To reiterate, the tracing service treats producers as inherently
untrusted/adversarial, so its implementation should never attempt to use
a file descriptor that isn't otherwise validated (such as checking seals
for the memfds).
Example denial from a chromium apk that is exercising this path:
traced : type=1400 audit(0.0:80): avc: denied { use } for
path=2F6D656D66643A706572666574746F5F73686D656D202864656C6574656429
dev="tmpfs" ino=151536 scontext=u:r:traced:s0
tcontext=u:r:untrusted_app_29:s0:c136,c256,c512,c768 tclass=fd
permissive=0
(deobfuscated path in the denial: /memfd:perfetto_shmem (deleted))
Tested: experimental chromium apk no longer crashes when trying to hand
over shared memory to traced
Bug: 148841422
Change-Id: I7390fb174e2083ba7693c3160da44b4cfa7b1c8b
The credstore service is a system service which backs the
android.security.identity.* Framework APIs. It essentially calls into
the Identity Credential HAL while providing persistent storage for
credentials.
Bug: 111446262
Test: atest android.security.identity.cts
Test: VtsHalIdentityTargetTest
Test: android.hardware.identity-support-lib-test
Change-Id: I5cd9a6ae810e764326355c0842e88c490f214c60
There are a lot of properties which is meant to be set once by
vendor_init. Most of them are configuration properties from vendor. This
introduces a macro to define such properties, which can help readability
and better security than using plain system_public_prop.
Bug: 148125056
Test: manual
Change-Id: I8b68e635d42119bafd1d22cba7957f583822ac7b
This concerns the data transfer between an untrusted producer process,
and the tracing service (traced daemon). They communicate over a
combination of a unix socket and shared memory.
Normally, the service creates the shared memory region, and hands it off
to the producer process (see perfetto_producer() macro). This patch
allows for an alternative scheme, where the producer process is allowed
to create the shared memory region, which will then be adopted by the
tracing service. The service already inherently doesn't trust the
producer, so it'll validate that the shared memory is appropriately
sealed before using it.
The immediate use-case is chrome's go/perfetto-startup-tracing-v2. But
this mode has advantages (e.g. being able to write to the shared memory
before connecting) for other producer domains as well.
Bug: 148841422
Change-Id: I90f864b900958792553f0208f4a0041dbf2892cc
The steps involved in setting up profiling and stack unwinding are
described in detail at go/perfetto-perf-android.
To summarize the interesting case: the daemon uses cpu-wide
perf_event_open, with userspace stack and register sampling on. For each
sample, it identifies whether the process is profileable, and obtains
the FDs for /proc/[pid]/{maps,mem} using a dedicated RT signal (with the
bionic signal handler handing over the FDs over a dedicated socket). It
then uses libunwindstack to unwind & symbolize the stacks, sending the
results to the central tracing daemon (traced).
This patch covers the app profiling use-cases. Splitting out the
"profile most things on debug builds" into a separate patch for easier
review.
Most of the exceptions in domain.te & coredomain.te come from the
"vendor_file_type" allow-rule. We want a subset of that (effectively all
libraries/executables), but I believe that in practice it's hard to use
just the specific subtypes, and we're better off allowing access to all
vendor_file_type files.
Bug: 137092007
Change-Id: I4aa482cfb3f9fb2fabf02e1dff92e2b5ce121a47
This patch adds the necessary rules to support the existing usage of
perf_event_open by the system partition, which almost exclusively
concerns the simpleperf profiler. A new domain is introduced for some
(but not all) executions of the system image simpleperf. The following
configurations are supported:
* shell -> shell process (no domain transition)
* shell -> debuggable app (through shell -> runas -> runas_app)
* shell -> profileable app (through shell -> simpleperf_app_runner ->
untrusted_app -> simpleperf)
* debuggable/profile app -> self (through untrusted_app -> simpleperf)
simpleperf_app_runner still enters the untrusted_app domain immediately
before exec to properly inherit the categories related to MLS. My
understanding is that a direct transition would require modifying
external/selinux and seapp_contexts as with "fromRunAs", which seems
unnecessarily complex for this case.
runas_app can still run side-loaded binaries and use perf_event_open,
but it checks that the target app is exactly "debuggable"
(profileability is insufficient).
system-wide profiling is effectively constrained to "su" on debug
builds.
See go/perf-event-open-security for a more detailed explanation of the
scenarios covered here.
Tested: "atest CtsSimpleperfTestCases" on crosshatch-user/userdebug
Tested: manual simpleperf invocations on crosshatch-userdebug
Bug: 137092007
Change-Id: I2100929bae6d81f336f72eff4235fd5a78b94066
In order for services registered with LazyServiceRegistrar to dynamically stop, servicemanager needs to be able to call into client processes (to notify them and trigger shutdown).
Bug: 143108344
Test: aidl_lazy_test
Change-Id: I402d0bcc5e668bf022162c7ce7393d5b77256479
init and dumpstate should be able to access all properties, but they are
in coredomain, so neverallow rules for vendor properties should be
changed in order to avoid conflicts.
Bug: 145339613
Test: add vendor_internal_prop manually and build.
Change-Id: If582870f855e4444f8ac0d091696c0c7fd833791
