To perform sdk sandbox data isolation, the zygote gets the selinux label
of SDK sandbox storage (e.g. /data/misc_{ce,de}/<user-id>/sdksandbox)
before tmpfs is mounted onto /data/misc_{ce,de} (or other volumes). It
relabels it back once bind mounting of required sandbox data is done.
This change allows for the zygote to perform these operations.
Bug: 214241165
Test: atest SdkSandboxStorageHostTest
Change-Id: I28d1709ab4601f0fb1788435453ed19d023dc80b
Creating a per-user encrypted directory such as /data/system_ce/0 and
the subdirectories in it too early has been a recurring bug. Typically,
individual services in system_server are to blame; system_server has
permission to create these directories, and it's easy to write
"mkdirs()" instead of "mkdir()". Such bugs are very bad, as they
prevent these directories from being encrypted, as encryption policies
can only be set on empty directories. Due to recent changes, a factory
reset is now forced in such cases, which helps detect these bugs;
however, it would be much better to prevent them in the first place.
This CL locks down the ability to create these directories to just vold
and init, or to just vold when possible. This is done by assigning new
types to the directories that contain these directories, and then only
allowing the needed domains to write to these parent directories. This
is similar to what https://r.android.com/1117297 did for /data itself.
Three new types are used instead of just one, since these directories
had three different types already (system_data_file, media_rw_data_file,
vendor_data_file), and this allows the policy to be a bit more precise.
A significant limitation is that /data/user/0 is currently being created
by init during early boot. Therefore, this CL doesn't help much for
/data/user/0, though it helps a lot for the other directories. As the
next step, I'll try to eliminate the /data/user/0 quirk. Anyway, this
CL is needed regardless of whether we're able to do that.
Test: Booted cuttlefish. Ran 'sm partition disk:253,32 private', then
created and deleted a user. Used 'ls -lZ' to check the relevant
SELinux labels on both internal and adoptable storage. Also did
similar tests on raven, with the addition of going through the
setup wizard and using an app that creates media files. No
relevant SELinux denials seen during any of this.
Bug: 156305599
Change-Id: I1fbdd180f56dd2fe4703763936f5850cef8ab0ba
Group together the rules for setting up app data isolation and get all
the comments up-to-date. Also remove some parts that aren't needed:
- 'allow zygote mnt_expand_file:dir mounton;' -- not needed. It might
have been thought that this was needed for mounting tmpfs on
/mnt/expand/$volume/user{,_de}, but those have type system_data_file.
- 'allow zygote mnt_expand_file:dir relabelto;' -- not needed, as
nothing is ever relabeled to this type.
- 'allow zygote media_rw_data_file:dir getattr;' -- not needed to create
bind mounts. The similar rules for user_profile_* don't include this.
- 'allow zygote mirror_data_file:dir r_dir_perms;' -- tighten to just
the required search permission.
- 'allow zygote system_data_file:dir getattr;' -- redundant with 'allow
zygote system_data_file:dir r_dir_perms;', and not needed for the
stated reason of "Get inode of directories for app data isolation".
Test: booted Cuttlefish, no denials seen.
Change-Id: Id77b8c81625fd785a5d0d88c37d7c85b8fff7244
Credit to Himanshu Agrawal <quic_hagraw@quicinc.com> for this fix.
Like we do with cgroup_v2, we set attribute permission to cgroup
as well.
Test: On a Go device, which uses cgroup instead of cgroup_v2
Bug: 209933729
Change-Id: I5d58c9f549d205f1a8bdce6c5fba1cc833f2b492
Bug: 199200417
Test: Build cuttlefish with an 'android'-targeting RRO in a
vendor APEX. Observe no SELinux errors.
Change-Id: I4c73cb6d98b70282e10354d2596b261bd7c409db
As "/storage/emulated/0/Android/obb, /storage/emulated/0/Android/data" might be labeledfs (f2fs),
Zygote needs to be allowed to unmount labeledfs while unmounting "/storage".
Here's the warning if we do not add it.
avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0
Bug:192989523
Test:adb shell stop; adb shell start; check no warning log
Change-Id: I74ce9bed29ec7da536a261a4fea25628f3d382ef
Any FUSE filesystem will receive the 'fuse' type when mounted. It is
possible to change this behaviour by specifying the "context=" or
"fscontext=" option in mount().
Because 'fuse' has historically been used only for the emulated storage,
it also received the 'sdcard_type' attribute. Replace the 'sdcard_type'
attribute from 'fuse' with the new 'fusefs_type'. This attribute can be
attached on derived types (such as app_fusefs).
This change:
- Remove the neverallow restriction on this new type. This means any
custom FUSE implementation can be mounted/unmounted (if the correct
allow rule is added). See domain.te.
- Change the attribute of 'fuse' from 'sdcard_type' to 'fusefs_type'.
See file.te.
- Modify all references to 'sdcard_type' to explicitly include 'fuse'
for compatibility reason.
Bug: 177481425
Bug: 190804537
Test: Build and boot aosp_cf_x86_64_phone-userdebug
Change-Id: Id4e410a049f72647accd4c3cf43eaa55e94c318f
Due to aosp/1708274, ref data directory is now world accessible.
We need to fix ref data directory so that it does not leak app
visibility information.
Bug: 189787375
Test: AppDataIsolationTests
Change-Id: I4170bbe2eed672c765ee6a28bbc29ab683f67a0a
As data and obbs are already mounted to lowerfs, and we need per app visibility isolation to mount
on those directories.
Here's the warning if we do not add it.
3094 3094 W main : type=1400 audit(0.0:36): avc: denied { mounton } for path="/storage/emulated/0/Android/obb" dev="dm-5" ino=9206 scontext=u:r:zygote:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=dir permissive=0
Bug: 182997439
Test: No selinux warnings during boot.
Change-Id: Id78d793e70acf0d7699c006e19db6d7fda766bf1
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
Zygote will trigger sdcardfs to read and open media_rw_data_file:dir.
We can safely ignore this message.
Bug: 177248242
Test: Able to boot without selinux warning.
Change-Id: Ie9723ac79547bf857f55fc0e60b461210a4e4557
qemu.sf.lcd_density is rerefenced by surfaceflinger
and zygote.
Bug: 178144237
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iede75d1170aeac9d020d60a3a66a1f69cee46abf
Merged-In: Iede75d1170aeac9d020d60a3a66a1f69cee46abf
Bug: 168907513
Test: verified the correct working of the v2 uid/pid hierarchy in normal
and recovery modes
This reverts commit aa8bb3a29b.
Change-Id: Ib344d500ea49b86e862e223ab58a16601eebef47
a54bed6907
Bug: 151660495
Test: verified proper boot in regular mode and proper working of adb in
recovery
Change-Id: Id70d27a6162af6ede94661005d80a2a780057089
odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
user_profile_data_file is mlstrustedobject. And it needs to be,
because we want untrusted apps to be able to write to their profile
files, but they do not have levels.
But now we want to apply levels in the parent directories that have
the same label, and we want them to work so they need to not be
MLS-exempt. To resolve that we introduce a new label,
user_profile_root_file, which is applied to those directories (but no
files). We grant mostly the same access to the new label as
directories with the existing label.
Apart from appdomain, almost every domain which accesses
user_profile_data_file, and now user_profile_root_file, is already
mlstrustedsubject and so can't be affected by this change. The
exception is postinstall_dexopt which we now make mlstrustedobject.
Bug: 141677108
Bug: 175311045
Test: Manual: flash with wipe
Test: Manual: flash on top of older version
Test: Manual: install & uninstall apps
Test: Manual: create & remove user
Test: Presubmits.
Change-Id: I4e0def3d513b129d6c292f7edb076db341b4a2b3
the cgroups v2 uid/gid hierarchy will replace cgroup for all sepolicy
rules. For this reason, old rules have to be duplicated to cgroup_v2,
plus some rules must be added to allow the ownership change for cgroup
files created by init and zygote.
Test: booted device, verified correct access from init, system_server
and zygote to the uid/pid cgroup files
Change-Id: I80c2a069b0fb409b442e1160148ddc48e31d6809
This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
This mostly reverts the revert in commit
b01e1d97bf, restoring commit
27e0c740f1. Changes to check_seapp to
enforce use of app_data_file_type is omitted, to be included in a
following CL.
Test: Presubmits
Bug: 171795911
Change-Id: I02b31e7b3d5634c94763387284b5a154fe5b71b4
This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
Also extend check_seapp to check that all types specified in
seapp_contexts files have the attribute, to ensure that the neverallow
rules apply to them. As a small bonus, also verify that domain and
type values are actually types not attributes.
Test: Presubmits
Test: Manual: specify an invalid type, build breaks.
Bug: 171795911
Change-Id: Iab6018af449dab3b407824e635dc62e3d81e07c9
To remove bad context names exported[23]_default_prop
Bug: 155844385
Test: m selinux_policy
Change-Id: Ic4bbc8e45d810368a96f6985c2234798e73be82d
Merged-In: Ic4bbc8e45d810368a96f6985c2234798e73be82d
(cherry picked from commit 072b01438e)
/apex/apex-info-file.xml is labeled as apex_info_file. It is
created/written by apexd once by apexd, and can be read by zygote and
system_server. The content of the file is essentially the same as the
return value of getAllPackages() call to apexd.
Bug: 154823184
Test: m
Merged-In: Ic6af79ddebf465b389d9dcb5fd569d3a786423b2
(cherry picked from commit f1de4c02cc)
Change-Id: Ic6af79ddebf465b389d9dcb5fd569d3a786423b2
Three properties are declared as vendor-init-settable:
ro.media.xml_variant.codecs
ro.media.xml_variant.codecs_performance
ro.media.xml_variant.profiles
media_codecs.xml can now be named
media_codecs${ro.media.xml_variant.codecs}.xml
media_codecs_performance.xml can now be named
media_codecs_performance${ro.media.xml_variant.codecs_performance}.xml
media_profiles_V1_0 can now be named
media_profiles${ro.media.xml_variant.profiles}.xml
Test: Rename "media_codecs.xml" to "media_codecs_test.xml",
set ro.media.xml_variant.codecs to "_test", then
call "stagefright -i".
Test: Rename "media_codecs_performance.xml" to
"media_codecs_performance_test.xml",
set ro.media.xml_variant.codecs_performance to "_test", then
run android.media.cts.VideoDecoderPerfTest.
Test: Rename "media_profiles_V1_0.xml" to "media_profiles_test.xml",
set ro.media.xml_variant.profiles to "_test", then
run vts_mediaProfiles_validate_test.
Bug: 142102953
Change-Id: I407a0a327fcc8e799bb4079b11048a497565be48
/mnt/pass_through was introduced to allow the FUSE daemon unrestricted
access to the lower filesystem (or sdcardfs).
At zygote fork time, the FUSE daemon will have /mnt/pass_through/0
bind mounted to /storage instead of /mnt/user/0. To keep /sdcard
(symlink to /storage/self/primary) paths working, we create a
'self' directory with an additional 'primary' symlink to
/mnt/pass_through/0/emulated/0 which is a FUSE mount point.
The following components need varying sepolicy privileges:
Vold: Creates the self/primary symlink and mounts the lower filesystem
on /mnt/pass_through/0/emulated. So needs create_dir and mount access
+ create_file access for the symlink
zygote: In case zygote starts an app before vold sets up the paths.
This is unlikely but can happen if the FUSE daemon (a zygote forked app)
is started before system_server completes vold mounts.
Same sepolicy requirements as vold
installd: Needs to clear/destroy app data using lower filesystem
mounted on /mnt/pass_through so needs read_dir access to walk
/mnt/pass_through
priv_app (FUSE daemon): Needs to server content from the lower
filesystem mounted on /mnt/pass_through so needs read_dir access to
walk /mnt/pass_through
Bug: 135341433
Test: adb shell ls /mnt/pass_through/0/self/primary
Change-Id: I16e35b9007c2143282600c56adbc9468a1b7f240
System_server will listen on incoming packets from zygotes.
Bug: 136036078
Test: atest CtsAppExitTestCases:ActivityManagerAppExitInfoTest
Change-Id: I42feaa317615b90c5277cd82191e677548888a71
Also, allow zygote to scan dirs in /mnt/expand and relabel.
Test: No denials at boot
Test: No denials seen when creating mounts
Bug: 143937733
Change-Id: I86e77d27f5e9fb2f5852f787c7e5d9179c7404aa
Zygote/Installd now can do the following operations in app data directory:
- Mount on it
- Create directories in it
- Mount directory for each app data, and get/set attributes
Bug: 143937733
Test: No denials at boot
Test: No denials seen when creating mounts
Change-Id: I6e852a5f5182f1abcb3136a3b23ccea69c3328db
This reverts commit 9f02b30a72.
This is no longer needed, because we never shipped app storage
sandboxes.
Bug: 130812417
Test: builds
Change-Id: Ia1f51db4904742d2ef15222f2350c67af0dd4a28
zygote now allocates JIT memory using libcutils API (aosp/1135101)
instead of going to /dev/ashmem directly, which requires execute
permissions to ashmem_libcutils_device.
Bug: 134434505
Change-Id: I3b5eeac1ec06d8d70da327743174ca83eec6b41c
Test: boot crosshatch
zygote now allocates JIT memory using libcutils API (aosp/1135101)
instead of going to /dev/ashmem directly, which requires execute
permissions to ashmem_libcutils_device.
Bug: 134434505
Test: boot crosshatch
Change-Id: I0a54d64bd4656fafd2f03701d7828cfa94c08f04
Ashmem FD selinux labels have recently been changed (aosp/1127917) from
"ashmemd" to the label of the whichever process opens the fd, which
resulted in the following denial:
avc: denied { use } for
path="/dev/ashmemf5dc2dbf-d1e7-457e-b694-93c84704135e" dev="tmpfs"
ino=18972 ioctlcmd=0x7704 scontext=u:r:zygote:s0
tcontext=u:r:system_server:s0 tclass=fd permissive=1
Test: m selinux_policy
Change-Id: I4880420014bda21cd4f83e3d6190c3cfaa76822f
This is so that zygote can create the JIT cache with memfd_create
(or ashmem when memfd is not available).
Test: boot
Bug: 119800099
Change-Id: I88f1f6b1c930a8d22985b306a238f60b4af59f9c
During preloading resources, zygote scans the overlay directories of
supported partitions looking for android RROs to apply statically. Zygote
currently is allowed to read overlays in /oem/overlay, but zygote does
not have the search permission to be able to scan /oem.
Without this patch, this denial is logged:
04-04 14:57:40.136 876 876 I auditd : type=1400 audit(0.0:9):
avc: denied { search } for comm="main" name="oem" dev="dm-3" ino=46
scontext=u:r:zygote:s0 tcontext=u:object_r:oemfs:s0 tclass=dir
permissive=0
Bug: 121033532
Test: booting without denials and stat oem succeeds
Change-Id: I661f3e0aff7ec3513870d08ddc122fc359b8f995
