Ideally, public should only contain APIs (types / attributes) for
vendor. The other statements like allow/neverallow/typeattributes are
regarded as implementation detail for platform and should be in private.
Bug: 232023812
Test: m selinux_policy
Test: diff <(git diff --staged | grep "^-" | cut -b2- | sort) \
<(git diff --staged | grep "^+" | cut -b2- | sort)
Test: remove comments on plat_sepolicy.cil, replace base_typeattr_*
to base_typeattr and then compare old and new plat_sepolicy.cil
Change-Id: I5e7d2da4465ab0216de6bacdf03077d37f6ffe12
During OTA install, update_engine needs to read this file to determine
if overlayfs is enabled, as OTA requires overlayfs to be disabled.
The selinux denial looks like
audit(0.0:242): avc: denied { read } for name="filesystems"
dev="proc" ino=4026532076 scontext=u:r:update_engine:s0
tcontext=u:object_r:proc_filesystems:s0 tclass=file permissive=0
Bug: 309812002
Test: th
Change-Id: I10903ced21e79c90dec45fb40ecd169d98c94e89
Starting in Android 11, Android unconditionally disables kernel module
autoloading (https://r.android.com/1254748) in such a way that even the
SELinux permission does not get checked. Therefore, all the SELinux
rules that allow or dontaudit the module_request permission are no
longer necessary. Their presence or absence makes no difference.
Bug: 130424539
Test: Booted Cuttlefish, no SELinux denials.
Change-Id: Ib80e3c8af83478ba2c38d3e8a8ae4e1192786b57
Grant ReadDefaultFstab() callers
allow scontext { metadata_file gsi_metadata_file_type }:dir search;
allow scontext gsi_public_metadata_file:file r_file_perms;
so they can search / read DSU metadata files.
The DSU metadata files are required to deduce the correct fstab.
Also tighten the neverallow rules in gsid.te.
Bug: 181110285
Test: Build pass, presubmit test
Test: Boot and check avc denials
Test: Boot with DSU and check avc denials
Change-Id: Ie464b9a8f7a89f9cf8f4e217dad1322ba3ad0633
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
Now that we have proper API using which update_engine can ask apexd to
reserve space, we no longer need to allow update_engine access to
directories at /data/apex.
Instead, apexd should get those permission.
Bug: 172911822
Test: atest ApexHandlerAndroidTest
Change-Id: I3a575eead0ac2fef69e275077e5862e721dc0fbf
This is the stable AIDL binder interface that update_engine exposes in
addition to update_engine_service.
Test: run update_engine
Bug: 160996544
Change-Id: I28ba11810844373d48c8c203f79e98150f932942
public/property split is landed to selectively export public types to
vendors. So rules happening within system should be in private. This
introduces private/property.te and moves all allow and neverallow rules
from any coredomains to system defiend properties.
Bug: 150331497
Test: system/sepolicy/tools/build_policies.sh
Change-Id: I0d929024ae9f4ae3830d4bf3d59e999febb22cbe
Merged-In: I0d929024ae9f4ae3830d4bf3d59e999febb22cbe
(cherry picked from commit 42c7d8966c)
recovery is excluded because it is not an interesting code
path.
Test: apply OTA, cancel, delete OTA states, then apply again
to trigger CancelUpdate() code path, see logs
Bug: 148818798
Change-Id: I3baac977af54ac0a09c9b732fd172469c9f51627
We've moved GMS core to its own domain, and this permission should no
longer be applied to the broader priv_app domain.
Before we delete the rule, we are auditing it to see if any other
privapps need it.
Bug: 142672293
Test: TH
Change-Id: I29c29739f4c3caf5d24361b69adc584047da0ef0
We need this permission now that GMS core runs in its own domain and not
in the priv_app domain.
Bug: 145379440
Bug: 142672293
Test: TH
Change-Id: Idc4bf6863ba767d287c218c07d0eb5aebbe50f91
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
update_engine tries to determine the parent path for all devices (e.g.
/dev/block/by-name) by reading the default fstab and looking for the misc
device. ReadDefaultFstab() checks whether a GSI is running by checking
gsi_metadata_file. We never apply OTAs when GSI is running, so just deny
the access.
Test: no selinux denials
Fixes: 139283697
Change-Id: I3cba28ccb6871b328ab697a4a8f3476ac72f7bed
- /data/gsi/ota/* now has the type ota_image_data_file. At runtime
during an OTA, update_engine uses libsnapshot to talk to gsid
to create these images as a backing storage of snapshots. These
"COW images" stores the changes update_engine has applied to
the partitions.
If the update is successful, these changes will be merged to the
partitions, and these images will be teared down. If the update
fails, these images will be deleted after rolling back to the
previous slot.
- /metadata/gsi/ota/* now has the type ota_metadata_file. At runtime
during an OTA, update_engine and gsid stores update states and
information of the created snapshots there. At next boot, init
reads these files to re-create the snapshots.
Beside these assignments, this CL also allows gsid and update_engine
to have the these permissions to do these operations.
Bug: 135752105
Test: apply OTA, no failure
Change-Id: Ibd53cacb6b4ee569c33cffbc18b1b801b62265de
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
We introduced a new API to allow Device Owner to install an OTA file on disk.
This in turn requires system_server to be able to copy the OTA file to a known
OTA file location, call into update_engine to start the installation and let
update_engine to call back to the system_server to deliver any error conditions
asynchronously. This CL modifies the SELinux policy to allow these interaction.
Test: manual in TestDPC, CTS tests for negative cases: atest com.android.cts.devicepolicy.DeviceOwnerTest#testInstallUpdate
Change-Id: Id1fbea9111f753c5c80f270c269ecb9ef141cd79
Bug: 111173669
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
commit 9b2e0cbeea added a new
self:global_capability_class_set macro that covers both self:capability
and self:cap_userns. Apply the new macro to various self:capability
references that have cropped up since then.
Bug: 112307595
Test: policy diff shows new rules are all cap_userns
Change-Id: I3eb38ef07532a8e693fd549dfdbc4a6df5329609
We often see the following denials:
avc: denied { sys_rawio } for comm="update_engine" capability=17 scontext=u:r:update_engine:s0 tcontext=u:r:update_engine:s0 tclass=capability permissive=0
avc: denied { sys_rawio } for comm="boot@1.0-servic" capability=17 scontext=u:r:hal_bootctl_default:s0 tcontext=u:r:hal_bootctl_default:s0 tclass=capability permissive=0
These are benign, so we are hiding them.
Bug: 37778617
Test: Boot device.
Change-Id: Iac196653933d79aa9cdeef7670076f0efc97b44a
tagSocket() now results in netd performing these actions on behalf
of the calling process.
Remove direct access to:
/dev/xt_qtaguid
/proc/net/xt_qtaguid/ctrl
Bug: 68774956
Test: -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AppSecurityTests
-m CtsNativeNetTestCases
Test: stream youtube, browse chrome
Test: go/manual-ab-ota
Change-Id: I6a044f304c3ec4e7c6043aebeb1ae63c9c5a0beb
In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.
This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.
This is essentially:
1. New global_capability_class_set and global_capability2_class_set
that match capability+cap_userns and capability2+cap2_userns,
respectively.
2. s/self:capability/self:global_capability_class_set/g
3. s/self:capability2/self:global_capability2_class_set/g
4. Add cap_userns and cap2_userns to the existing capability_class_set
so that it covers all capabilities. This set was used by several
neverallow and dontaudit rules, and I confirmed that the new
classes are still appropriate.
Test: diff new policy against old and confirm that all new rules add
only cap_userns or cap2_userns;
Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831
Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f
Add label update_engine_log_data_file for log files created by
update engine in directory /data/misc/update_engine_log.
Bug: 65568605
Test: manual
Change-Id: I379db82a0ea540e41cb3b8e03f93d9ce64fac7c9
New types:
1. proc_random
2. sysfs_dt_firmware_android
Labeled:
1. /proc/sys/kernel/random as proc_random.
2. /sys/firmware/devicetree/base/firmware/android/{compatible, fstab,
vbmeta} as sysfs_dt_firmware_android.
Changed access:
1. uncrypt, update_engine, postinstall_dexopt have access to generic proc
and sysfs labels removed.
2. appropriate permissions were added to uncrypt, update_engine,
update_engine_common, postinstall_dexopt.
Bug: 67416435
Bug: 67416336
Test: fake ota go/manual-ab-ota runs without denials
Test: adb sideload runs without denials to new types
Change-Id: Id31310ceb151a18652fcbb58037a0b90c1f6505a
Grant update_engine access to sysfs.
Ran fake ota go/manual-ab-ota, and this denial was fixed:
avc: denied { read } for pid=912 comm="update_engine" name="compatible"
dev="sysfs" ino=17399 scontext=u:r:update_engine:s0
tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
Test: boots with no new denials
Change-Id: I8697da3af254aea1cec44d9dbb1eca18be31859c
This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.
Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
permissions.
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b
Vendor and system components are only allowed to share files by
passing open FDs over HIDL. Ban all directory access and all file
accesses other than what can be applied to an open file:
stat/read/write/append.
This commit marks core data types as core_data_file_type and bans
access to non-core domains with an exemption for apps. A temporary
exemption is also granted to domains that currently rely on
access with TODOs and bug number for each exemption.
Bug: 34980020
Test: Build and boot Marlin. Make phone call, watch youtube video.
No new denials observed.
Change-Id: I320dd30f9f0a5bf2f9bb218776b4bccdb529b197
This switches Boot Control HAL policy to the design which enables us
to conditionally remove unnecessary rules from domains which are
clients of Boot Control HAL.
Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control HAL
runs in passthrough mode (i.e., inside the client's process). When the
HAL runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting
hal_bootctl are not granted to client domains.
Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.
P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.
Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
1. make dist
2. Ensure device has network connectivity
3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf
Introduce the add_service() macro which wraps up add/find
permissions for the source domain with a neverallow preventing
others from adding it. Only a particular domain should
add a particular service.
Use the add_service() macro to automatically add a neverallow
that prevents other domains from adding the service.
mediadrmserver was adding services labeled mediaserver_service.
Drop the add permission as it should just need the find
permission.
Additionally, the macro adds the { add find } permission which
causes some existing neverallow's to assert. Adjust those
neverallow's so "self" can always find.
Test: compile and run on hikey and emulator. No new denials were
found, and all services, where applicable, seem to be running OK.
Change-Id: Ibbd2a5304edd5f8b877bc86852b0694732be993c
Signed-off-by: William Roberts <william.c.roberts@intel.com>
The service running the boot control HAL needs the permissions
provided by the boot_control_hal attribute. update_engine and
update_verifier still also need these permissions in order
to successfully call the new HAL in pass-through mode, but also
need permission to call the new service.
Bug: 31864052
Test: Built and confirmed no permission denials.
Change-Id: I2a6fdd5cf79b9e461d7cc14bd5b7abd6481ed911
Signed-off-by: Connor O'Brien <connoro@google.com>
Grant boot_control_hal permissions to the hal_boot service;
update_engine and update_verifier can call that service rather
than using those permissions themselves.
Bug: 31864052
Test: `bootctl set-active-boot-slot 1`
Change-Id: I5188bc32e7933d4a0f5135b3246df119d3523d69
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
