This is to remove exported3_default_prop. Contexts of these properties
are changed.
- ro.boot.wificountrycode
This becomes wifi_config_prop
- ro.opengles.version
This becomes graphics_config_prop. Also it's read by various domains, so
graphics_config_prop is now readable from coredomain.
- persist.config.calibration_fac
This becomes camera_calibration_prop. It's only readable by appdomain.
Bug: 155844385
Test: no denials on Pixel devices
Test: connect wifi
Change-Id: If2b6c10fa124e29d1612a8f94ae18b223849e2a9
This removes bad context names "exported*_prop". Property contexts of
following properties are changed. All properties are settable only by
vendor-init.
- ro.config.per_app_memcg
This becomes lmkd_config_prop.
- ro.zygote
This becomes dalvik_config_prop.
- ro.oem_unlock_supported
This becomes oem_unlock_prop. It's readable by system_app which includes
Settings apps.
- ro.storage_manager.enabled
This becomes storagemanagr_config_prop. It's readable by coredomain.
Various domains in coredomain seem to read it.
- sendbug.preferred.domain
This bcomes sendbug_config_prop. It's readable by appdomain.
There are still 3 more exported3_default_prop, which are going to be
tracked individually.
Bug: 155844385
Test: selinux denial check on Pixel devices
Change-Id: I340c903ca7bda98a92d0f157c65f6833ed00df05
vts_config_prop and vts_status_prop are added to remove exported*_prop.
ro.vts.coverage becomes vts_config_prop, and vts.native_server.on
becomes vts_status_prop.
Bug: 155844385
Test: Run some vts and then getprop, e.g. atest \
VtsHalAudioEffectV4_0TargetTest && adb shell getprop
Test: ro.vts.coverage is read without denials
Change-Id: Ic3532ef0ae7083db8d619d80e2b73249f87981ce
dexoptanalyzer need read access on the secondary
dex files and of the main apk files in order to successfully evaluate
and optimize them.
Example of denial:
audit(0.0:30): avc: denied { read } for
path="/data/app/~~Zux_isdY0NBkRWPp01oAVg==/com.example.secondaryrepro-wH9zezMSCzIjcKdIMtrw7A==/base.apk"
dev="vdc" ino=40966 scontext=u:r:dexoptanalyzer:s0
tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=0
app=com.example.secondaryrepro
Test: adb shell cmd package compile -r bg-dexopt --secondary-dex app
Bug: 160471235
Bug: 160351055
Change-Id: Id0bda5237d3ce1620d4f6ee89595836b4e1f3abf
To remove bad context names, two contexts are added.
- telephony_config_prop
- telephony_status_prop
exported_radio_prop, exported2_radio_prop are removed. Cleaning up
exported3_radio_prop will be a follow-up task.
Exempt-From-Owner-Approval: cherry-pick
Bug: 152471138
Bug: 155844385
Test: boot and see no denials
Test: usim works on blueline
Change-Id: Iff9a4635c709f3ebe266cd811df3a1b4d3a242c2
Merged-In: Iff9a4635c709f3ebe266cd811df3a1b4d3a242c2
(cherry picked from commit 4d36eae8af)
1. Allow gpuservice to access tracepoint id
2. Allow gpuservice to access bpf program
3. Allow gpuservice to attach bpf program to tracepoint
4. Allow gpuservice to access bpf filesystem
5. Allow gpuservice to run bpf program and read map through bpfloader
6. Allow gpuservice to check a property to ensure bpf program loaded
Bug: 136023082
Test: adb shell dumpsys gpu --gpumem
Change-Id: Ic808a7e452b71c54908cdff806f41f51ab66ffd8
Exported properties init.svc.* were world-readable, so making them
world-readable again to fix selinux denials.
Bug: 157474281
Test: m selinux_policy
Change-Id: I6d5a28b68061896e9cd2584c47aa60f6d36ed53f
compatible_property_only is meaningless to new types introduced after
Android P because the macro is for types which should have different
accessibilities depending on the device's launching API level.
Bug: N/A
Test: system/sepolicy/tools/build_policies.sh
Change-Id: If6b1cf5e4203c74ee65f170bd18c3a354dca2fd4
To remove bad context names "exported*_prop". Other init.svc.*
properties explicitly become system internal prop.
Bug: 155844385
Test: boot and see no denials
Change-Id: I7a3b4103a4cea77035a6e831e3b6a49a45f15a35
For whatever reason sys.usb.config* has been labeled as
system_radio_prop, which doesn't make sense. Changing context name as
usb_prop. For the same reason exported_system_radio_prop is also
renamed to usb-related names.
Bug: 71814576
Bug: 154885206
Test: m selinux_policy
Change-Id: If30bc620dbeac926a8b9bcde908357fda739a6c1
Merged-In: If30bc620dbeac926a8b9bcde908357fda739a6c1
(cherry picked from commit 44fbcdb677)
persist.sys.dalvik.vm.lib.2 is moved to a new context
dalvik_runtime_prop from bad context name.
Bug: 154885206
Test: boot device and see logcat
Change-Id: I9dea95105c266088d5f071bf2d890048f0999b0b
MediaPlayer cannot load a video from RRO packages.
So, add allow rules which is necessary to play the video.
Bug: b/154795779
Test: check if MediaPlayer can load a video in RRO
Change-Id: I06eed146b6e70a548b6b4f4faf56ba2bccd68140
In order to track time in state data using eBPF, system_server needs
to be able to attach BPF programs to tracepoints, which involves:
- calling perf_event_open and the PERF_EVENT_IOC_SET_BPF ioctl
- running BPF programs
- reading tracepoint ids from tracefs
Grant system_server the necessary permissions for these tasks
Test: modify system_server to try to attach programs; check for
denials
Bug: 138317993
Change-Id: I07dafd325a9c57d53767a09d4ca7b0fb2dd2d328
Signed-off-by: Connor O'Brien <connoro@google.com>
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
/system/bin/iorapd fork+execs into /system/bin/iorap_prefetcherd during
startup
See also go/android-iorap-security for the design doc
Bug: 137403231
Change-Id: Ie8949c7927a98e0ab757bc46230c589b5a496360
all_untrusted_apps apart from untrusted_app_{25, 27} and mediaprovider
are now expected to go to ashmemd for /dev/ashmem fds.
Give coredomain access to ashmemd, because ashmemd is the default way
for coredomain to get a /dev/ashmem fd.
Bug: 113362644
Test: device boots, ashmemd running
Test: Chrome app works
Test: "lsof /system/lib64/libashmemd_client.so" shows
libashmemd_client.so being loaded into apps.
Change-Id: I279448c3104c5d08a1fefe31730488924ce1b37a
init now creates two mount namespaces one for pre-apexd processes and
the other for post-apexd processes. This is to mount different files to
the same mount point at /bionic. For pre-apexd processes, the bootstrap
Bionic is mounted. For post-apexd processes, the default Bionic (from
the runtime APEX) is mounted.
Using unshare and setns, init first starts with the mount namespace for
the pre-apexd and then switches to the other mount namespace when APEXes
are ready. It then occasionally switches to pre-apexd mount namespace
when it has to re-launch a pre-apexd process (e.g. the process has
crashed, etc.)
In doing so, read access to /proc/self/ns/mnt is granted to init as
well.
Bug: 120266448
Bug: 122717176
Test: m device boots
Change-Id: Idbf15cbf5cc36b9993d718d4d887cd8f23a94666
The application zygote is a new sort of zygote process that is a
child of the regular zygote. Each application zygote is tied to the
application for which it's launched. Once it's started, it will
pre-load some of the code for that specific application, much like
the regular zygote does for framework code.
Once the application zygote is up and running, it can spawn
isolated service processes that run in the isolated_app domain. These
services can then benefit from already having the relevant
application code and data pre-loaded.
The policy is largely the same as the webview_zygote domain,
however there are a few crucial points where the policy is different.
1) The app_zygote runs under the UID of the application that spawned
it.
2) During app_zygote launch, it will call a callback that is
controlled by the application, that allows the application to
pre-load code and data that it thinks is relevant.
Especially point 2 is imporant: it means that untrusted code can run
in the app_zygote context. This context is severely limited, and the
main concern is around the setgid/setuid capabilities. Those conerns
are mitigated by installing a seccomp filter that only allows
setgid/setuid to be called in a safe range.
Bug: 111434506
Test: app_zygote can start and fork children without denials.
Change-Id: I1cc49ee0042d41e5ac6eb81d8f8a10ba448d4832
The way we build and run CTS expects full_treble_only and
compatible_property_only macros to be applied to whole rules and not be
nested inside other rules.
Fixes: 122601363
Test: corresponding neverallow rule in auto-generated
SELinuxNeverallowRulesTest.java is parsed correctly.
Change-Id: Ibf5187cedca72510fe74c6dc55a75a54a86c02ff
When an app uses renderscript to compile a Script instance,
renderscript compiles and links the script using /system/bin/bcc and
/system/bin/ld.mc, then places the resulting shared library into the
application's code_cache directory. The application then dlopen()s the
resulting shared library.
Currently, this executable code is writable to the application. This
violates the W^X property (https://en.wikipedia.org/wiki/W%5EX), which
requires any executable code be immutable.
This change introduces a new label "rs_data_file". Files created by
/system/bin/bcc and /system/bin/ld.mc in the application's home
directory assume this label. This allows us to differentiate in
security policy between app created files, and files created by
renderscript on behalf of the application.
Apps are allowed to delete these files, but cannot create or write these
files. This is enforced through a neverallow compile time assertion.
Several exceptions are added to Treble neverallow assertions to support
this functionality. However, because renderscript was previously invoked
from an application context, this is not a Treble separation regression.
This change is needed to support blocking dlopen() for non-renderscript
/data/data files, which will be submitted in a followup change.
Bug: 112357170
Test: cts-tradefed run cts -m CtsRenderscriptTestCases
Change-Id: Ie38bbd94d26db8a418c2a049c24500a5463698a3
"iio_device", "radio_device" must not be accessed by coredomain on all
devices. And "tee_device" must not be accessed by coredomain on Treble
devices.
Bug: 110962171
Test: m selinux_policy
Test: mmma system/sepolicy
Change-Id: I27029b6579b41109c01c35c6ab5a992413f2de5c
According to go/sedenials (internal dogfooding), coredomain access to
following types is not exercised and can be removed:
iio_device
radio_device
tee_device
Access to audio_device is still needed since some ALSA interfaces
(/dev/snd/*) are directly used by system_server.
Bug: 110962171
Test: m selinux_policy
Change-Id: I740b99813e1f93136bfcaec087b74f0e03b259ad
Move rules / neverallow assertions from public to private policy. This
change, by itself, is a no-op, but will make future patches easier to
read. The only downside of this change is that it will make git blame
less effective.
Motivation: When rules are placed into the public directory, they cannot
reference a private type. A future change will modify these rules to
reference a private type.
Test: compiles
Bug: 112357170
Change-Id: I56003409b3a23370ddab31ec01d69ff45c80d7e5
We lose git history with this, but imo the rules being moved don't have
much reference material. Also, as we write more neverallow rules for
CKI, I'd like to consolidate them in private/coredomain.te
Test: m selinux_policy
Change-Id: I6d0c3d2af0c4dfe7dd3cb1d8836b4b5e00db37a4
vendor_init exists on the system partition, but it is meant to be an
extention of init that runs with vendor permissions for executing
vendor scripts, therefore it is not meant to be in coredomain.
Bug: 62875318
Test: boot walleye
Merged-In: I01af5c9f8b198674b15b90620d02725a6e7c1da6
Change-Id: I01af5c9f8b198674b15b90620d02725a6e7c1da6
This CL lists all the exported platform properties in
private/exported_property_contexts.
Additionally accessing core_property_type from vendor components is
restricted.
Instead public_readable_property_type is used to allow vendor components
to read exported platform properties, and accessibility from
vendor_init is also specified explicitly.
Note that whitelisting would be applied only if
PRODUCT_COMPATIBLE_PROPERTY is set on.
Bug: 38146102
Test: tested on walleye with PRODUCT_COMPATIBLE_PROPERTY=true
Change-Id: I304ba428cc4ca82668fec2ddeb17c971e7ec065e
