Add a domain for derive_sdk which is allowed to set
persist.com.android.sdkext.sdk_info, readable by all
apps (but should only be read by the BCP).
Bug: 137191822
Test: run derive_sdk, getprop persist.com.android.sdkext.sdk_info
Change-Id: I389116f45faad11fa5baa8d617dda30fb9acec7a
ro.apk_verity.mode was introduced in P on crosshatch. This change
changes the label from default_prop to a new property, apk_verity_prop.
ro.apk_verity.mode is set by vendor_init per build.prop, in order to
honor Treble split. It is also read by system_server and installd
currently.
Test: verify functioning without denials in dmesg
Bug: 142494008
Bug: 144164497
Change-Id: I1f24513d79237091cf30025bb7ca63282e23c739
This reverts commit baa06ee2cd.
Reason for revert: Added missing property name in vendor_init.te.
Bug: none
Test: none (other than neverallow checking)
Change-Id: I9e93bf4ea6ca3a4634f8f4cbce2f13c5f410883b
By default sys.init.userspace_reboot.* properties are internal to
/system partition. Only exception is
sys.init.userspace_reboot.in_progress which signals to all native
services (including vendor ones) that userspace reboot is happening,
hence it should be a system_public_prop.
Only init should be allowed to set userspace reboot related properties.
Bug: 135984674
Test: builds
Test: adb reboot userspace
Change-Id: Ibb04965be2d5bf6e81b34569aaaa1014ff61e0d3
The property is set to inform kernel to do a warm_reset on the next
reboot. This is useful to persist the logs to debug device boot
failures. More details in http://go/rvc-ota-persist-logs.
The property is set to 1 by update_engine after an OTA. And it's set to
0 by update_verifier or vold after we mark the current slot boot
successful.
The property is read by vendor_init. And according to its value,
vendor_init writes a particular sysfs file to schedule a warm reset
on the following reboot.
Without the new context, the denial message says:
[ 13.423163] audit: type=1107 audit(1746393.166:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=u:r:init:s0 msg='avc: denied { read } for property=ota.warm_reset pid=0 uid=0 gid=0 scontext=u:r:vendor_init:s0 tcontext=u:object_r:default_prop:s0 tclass=file permissive=0'
[ 23.096497] init: Unable to set property 'OTA.warm_reset' from uid:0 gid:2001 pid:841: SELinux permission check failed
[ 23.096574] type=1107 audit(1573768000.668:42): uid=0 auid=4294967295 ses=4294967295 subj=u:r:init:s0 msg='avc: denied { set } for property=OTA.warm_reset pid=841 uid=0 gid=2001 scontext=u:r:update_verifier:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service permissive=0'
[ 23.108430] update_verifier: Failed to reset the warm reset flag
Bug: 143489994
Test: check the property can be set by update_engine, and read by vendor_init
Change-Id: I87c12a53a138b72ecfed3ab6a4d846c20f5a8484
To support linker-specific property, sys.linker.* has been defined as
linker_prop. This will have get_prop access from domain so all binaries
can start with linker using proper property access level.
Bug: 138920271
Test: m -j && Confirmed from cuttlefish that get_prop errors are no longer found
Change-Id: Iaf584e0cbdd5bca3d5667e93cf9a6401e757a314
Used to restrict properties init.svc_debug_pid.*
Bug: 138114550
Test: getprop | grep init.svc_debug_pid only shows results on root
Change-Id: I0c10699deec4c548a2463a934e96b897ddee1678
/metadata/ota will store critical bits necessary to reify
system and vendor partition state during an OTA. It will be accessed
primarily by first-stage init, recovery/fastbootd, and update_engine.
Bug: 136678799
Test: manual test
Change-Id: Ib78cb96ac60ca11bb27d2b2fe011482e64ba0cf8
This property will be set by system_server (to indicate the currently
selected theme for device), and can be accessed by vendor init.rc.
avc: denied { read } for property=persist.sys.theme pid=0 uid=0 gid=0 scontext=u:r:vendor_init:s0 tcontext=u:object_r:theme_prop:s0 tclass=file
Bug: 113028175
Test: Set a vendor init trigger that waits on `persist.sys.theme`. Check
that the trigger fires without denial.
Change-Id: Ia85b1a8dfc118efdbb9337ca017c8fb7958dc386
Merged-In: Ibb4e392d5059b76059f36f7d11ba82cd65cbe970
(cherry picked from commit 75182a1ea6)
The bootstrap bionic (/system/lib/bootstrap/*) are only to the early
processes that are executed before the bionic libraries become available
via the runtime APEX. Allowing them to other processes is not needed and
sometimes causes a problem like b/123183824.
Bug: 123183824
Test: device boots to the UI
Test: atest CtsJniTestCases:android.jni.cts.JniStaticTest#test_linker_namespaces
Change-Id: Id7bba2e8ed1c9faf6aa85dbbdd89add04826b160
Property is NNAPI client-readable and writeable only by init/build.prop.
Bug: 129666983
Bug: 120483623
Test: flashed crosshatch/Cts tests for NNAPI
Change-Id: Ic4c0f176440610a2c54c078863f3d5382323cc65
These denials occur on boot when android_get_control_file also
changes from readlink() to realpath(), because realpath() will
lstat() the given path.
Some other domains (fastbootd, update_engine, etc.) also uses
libcutils to write to kernel log, where android_get_control_file()
is invoked, hence getattr is added to them as well.
04-28 06:15:22.290 618 618 I auditd : type=1400 audit(0.0:4): avc: denied { getattr } for comm="logd" path="/dev/kmsg" dev="tmpfs" ino=20917 scontext=u:r:logd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
03-20 19:52:23.431 900 900 I auditd : type=1400 audit(0.0:7): avc: denied { getattr } for comm="android.hardwar" path="/dev/kmsg" dev="tmpfs" ino=20917 scontext=u:r:hal_health_default:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
...
03-20 22:40:42.316 1 1 W init : type=1400 audit(0.0:33): avc: denied { getattr } for path="/dev/kmsg" dev="tmpfs" ino=21999 scontext=u:r:init:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
Test: no denials related to these
Change-Id: I5263dd6b64c06fb092f3461858f57a1a09107429
This change allows those daemons of the audio and Bluetooth which
include HALs to access the bluetooth_audio_hal_prop. This property is
used to force disable the new BluetoothAudio HAL.
- persist.bluetooth.bluetooth_audio_hal.disabled
Bug: 128825244
Test: audio HAL can access the property
Change-Id: I87a8ba57cfbcd7d3e4548aa96bc915d0cc6b2b74
This is an area that apexd can use to store session metadata, which
won't be rolled back with filesystem checkpointing.
Bug: 126740531
Test: builds
Change-Id: I5abbc500dc1b92aa46830829be76e7a4381eef91
The device OS and an installed GSI will both attempt to write
authentication data to the same weaver slots. To prevent this, we can
use the /metadata partition (required for GSI support) to communicate
which slots are in use between OS images.
To do this we define a new /metadata/password_slots directory and define
sepolicy to allow system_server (see PasswordSlotManager) to access it.
Bug: 123716647
Test: no denials on crosshatch
Change-Id: I8e3679d332503b5fb8a8eb6455de068c22eba30b
Some runtime properties require reboots and should be in the
native_boot namespace instead of native.
Bug: 120794191
Bug: 123524494
Test: set a property and ensure it can be read in AndroidRuntime.cpp
Change-Id: I1d1e984dcba26dd04d34a7d30fc63e1b75a8a311
The convention for native properties is to use _native suffix.
Bug: 123524494
Bug: 120794191
Test: set a property and ensure it can be read in AndroidRuntime.cpp
Change-Id: I69feab9be78f24d812b8f953d3ec06a5d8d18f15
Bug: 120794191
Bug: 123524494
Test: set a property and ensure it can be read in AndroidRuntime.cpp
Change-Id: Ib37102f35e9987d3d9baff83c45571a5d632ad50
Whitelist the persistent system properties that will be used as
flags in activity manager experiments.
Bug: 120794810
Test: m, flash, test getting flag value in ActivityManagerService.java
Change-Id: I90a10bc87d6db3a64347b62fd02e6f0b12ac9fa8
For input experiments that are enabled at boot time, allow system_server
to read and write the device config flags.
Bug: 120794829
Test: presubmit
Change-Id: I0f075a7579c593d4e07c3e31be529e34554068a6
For experiment flag testing, we add a flag netd and have
SEPolicy updates.
Test: add sepolicy, m -j, check GetServerConfigurableFlag function in netd
Bug:122050512
Change-Id: I21c844c277afc358085d80447f16e4c0d4eba5b3
I added ro.bionic.(2nd_)?_(arch|cpu_variant) to vendor system
properties. And have init to write them to files under dev/.
This change set SELinux rules for these properties and files.
For the system properties: vendor/default.prop will set them. init will
read them.
For the files /dev/cpu_variant:.*: init will write them. bionic libc
will read them. (Basically world readable).
This is to allow libc select the right optimized routine at runtime.
Like memcpy / strcmp etc.
Test: getprop to make sure the properties are set.
Test: ls -laZ to make sure /dev/cpu_variant:.* are correctly labeled.
Change-Id: I41662493dce30eae6d41bf0985709045c44247d3
device_config_flags_health_check_prop is used for enabling/disabling
program flags_health_check which is executed during device booting.
"1" means enabling health check actions in flags_health_check, other
values mean flags_health_check will not perform any action.
Test: build succeeded & manual test
Change-Id: I93739dc5d155e057d72d08fd13097eb63c1193b5
This will be needed if vendors remove a label, as vendor_init would
need to relabel from it (which would be unlabeled) to the new label.
Test: Build policy.
Change-Id: Ieea0fcd7379da26b2864b971f7773ed61f413bb9
A sysprop apexd.status is set by apexd, to that other components (i.e.
init) can determine whether APEXs are all successfully mounted or no
(i.e., being mounted).
The sysprop is only writable by apexd.
Bug: 117403679
Test: adb shell getprop apexd.status returns 'ready'.
Change-Id: I81bcb96e6c5cb9d899f29ffa84f91eab3820be25
What changed:
- Removed cgroup access from untrusted and priv apps.
- Settings app writes to /dev/stune/foreground/tasks, so system_app domain
retains access to cgroup.
- libcutils exports API to /dev/{cpuset, stune}/*. This API seems to be used
abundantly in native code. So added a blanket allow rule for (coredomain - apps)
to access cgroups.
- For now, only audit cgroup access from vendor domains. Ultimately, we want to
either constrain vendor access to individual domains or, even better, remove
vendor access and have platform manage cgroups exclusively.
Changes from original aosp/692189 which was reverted:
- There seem to be spurious denials from vendor-specific apps. So added
back access from { appdomain -all_untrusted_apps -priv_app } to cgroup.
Audit this access with intent to write explicit per-domain rules for it.
Bug: 110043362
Test: adb shell setprop ro.config.per_app_memcg true, device correctly populates
/dev/memcg on a per app basis on a device that supports that.
Test: aosp_sailfish, wahoo boot without cgroup denials
This reverts commit cacea25ed0.
Change-Id: I05ab404f348a864e8409d811346c8a0bf49bc47a
Remove kernel attack surface associated with ioctls on plain files. In
particular, we want to ensure that the ioctls FS_IOC_ENABLE_VERITY and
FS_IOC_MEASURE_VERITY are not exposed outside a whitelisted set of
entities. However, it's straight forward enough to turn on ioctl
whitelisting for everything, so we choose to do so.
Test: policy compiles and device boots
Test: device boots with data wipe
Test: device boots without data wipe
Change-Id: I545ae76dddaa2193890eeb1d404db79d1ffa13c2
This reverts commit 9899568f6c.
Reason for revert: Reports of high numbers of SELinux denials
showing up on the SELinux dashboard.
Bug: 110043362
Change-Id: Id8fc260c47ffd269ac2f15ff7dab668c959e3ab0
What changed:
- Removed cgroup access from untrusted and priv apps.
- Settings app writes to /dev/stune/foreground/tasks, so system_app domain
retains access to cgroup.
- libcutils exports API to /dev/{cpuset, stune}/*. This API seems to be used
abundantly in native code. So added a blanket allow rule for (coredomain - apps)
to access cgroups.
- For now, only audit cgroup access from vendor domains. Ultimately, we want to
either constrain vendor access to individual domains or, even better, remove
vendor access and have platform manage cgroups exclusively.
Bug: 110043362
Test: adb shell setprop ro.config.per_app_memcg true, device correctly populates
/dev/memcg on a per app basis on a device that supports that.
Test: aosp_sailfish, wahoo boot without cgroup denials
Change-Id: I9e441b26792f1edb1663c660bcff422ec7a6332b
system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.
Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.
Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
kernel commit 2a4c22426955d4fc04069811997b7390c0fb858e (fs: switch order
of CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH checks) swapped the order of
dac_override and dac_read_search checks. Domains that have dac_override
will now generate spurious denials for dac_read_search unless they also
have that permission. Since dac_override is a strict superset of
dac_read_search, grant dac_read_search to all domains that already have
dac_override to get rid of the denials.
Bug: 114280985
Bug: crbug.com/877588
Test: Booted on a device running 4.14.
Change-Id: I5c1c136b775cceeb7f170e139e8d4279e73267a4
Add additional compile time constraints on the ability to ptrace various
sensitive domains.
llkd: remove some domains which llkd should never ptrace, even on
debuggable builds, such as kernel threads and init.
crash_dump neverallows: Remove the ptrace neverallow checks because
it duplicates other neverallow assertions spread throughout the policy.
Test: policy compiles and device boots
Change-Id: Ia4240d1ce7143b983bb048e046bb4729d0af5a6e
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.
This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:
-user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
+user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
For now, this newly introduced label has no usage, so this change
is essentially a no-op.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
vendor_init needs to touch a bunch of files. Forgotten within this set
of permissions is the ability to mmap files.
Addresses the following denial:
avc: denied { map } for pid=1167 comm="init" path="/system/etc/selinux/plat_file_contexts" dev="vda1" ino=1845 scontext=u:r:vendor_init:s0 tcontext=u:object_r:file_contexts_file:s0 tclass=file permissive=0
While I'm here, add mmap() support to other areas where it's likely
needed.
Bug: 111742629
Test: make -j80, ran emulator
Change-Id: Icab00e45ae88f0d86be66d85a22e018af6ffcd75
