Properties are now broken up from a single /dev/__properties__ file into
multiple files, one per property label. This commit provides the
mechanism to control read access to each of these files and therefore
sets of properties.
This allows full access for all domains to each of these new property
files to match the current permissions of /dev/__properties__. Future
commits will restrict the access.
Bug: 21852512
Change-Id: Ie9e43968acc7ac3b88e354a0bdfac75b8a710094
This allow bspatch to have same perssion as update_engine.
Also added a rule to allow update_engine to execute bspatch.
Bug: 24478450
Test: No more permission deny during delta update.
Change-Id: If94bc703b2f3fc32f901f0d7f300934316d4e9a4
The directory is to be used in eng/userdebug build to store method
traces (previously stored in /data/dalvik-cache/profiles).
Bug: 25612377
Change-Id: Ia4365a8d1f13d33ee54115dc5e3bf62786503993
1) Don't use the generic "system_data_file" for the files in /data/nativetest.
Rather, ensure it has it's own special label. This allows us to distinguish
these files from other files in SELinux policy.
2) Allow the shell user to execute files from /data/nativetest, on
userdebug or eng builds only.
3) Add a neverallow rule (compile time assertion + CTS test) that nobody
is allowed to execute these files on user builds, and only the shell user
is allowed to execute these files on userdebug/eng builds.
Bug: 25340994
Change-Id: I3e292cdd1908f342699d6c52f8bbbe6065359413
Simplify SELinux policy by deleting the procrank SELinux domain.
procrank only exists on userdebug/eng builds, and anyone wanting
to run procrank can just su to root.
Bug: 18342188
Change-Id: I71adc86a137c21f170d983e320ab55be79457c16
The update_engine daemon from Brillo is expected to be used also in
Android so move its selinux policy to AOSP.
Put update_engine in the whitelist (currently only has the recovery
there) allowing it to bypass the notallow for writing to partititions
labeled as system_block_device.
Also introduce the misc_block_device dev_type as update_engine in some
configurations may need to read/write the misc partition. Start
migrating uncrypt to use this instead of overly broad
block_device:blk_file access.
Bug: 23186405
Test: Manually tested with Brillo build.
Change-Id: Icf8cdb4133d4bbdf14bacc6c0fa7418810ac307a
Apply the same sepolicy used on dhcpcd to dhcpcd-6.8.2,
which is have it run with the dhcp context, and have its
data files possess the dhcp_data_file context.
BUG: 22956197
Change-Id: I7915b694038bb309d93691ef5d4d293593ef3b5e
Since ram devices are labeled in base contexts, also add a label
for devices using zram.
Change-Id: I002baebf40246e78c6f9fb367ac6fb019101cc86
Signed-off-by: William Roberts <william.c.roberts@intel.com>
We have a bunch of magic that mounts the correct view of storage
access based on the runtime permissions of an app, but we forgot to
protect the real underlying data sources; oops.
This series of changes just bumps the directory heirarchy one level
to give us /mnt/runtime which we can mask off as 0700 to prevent
people from jumping to the exposed internals.
Also add CTS tests to verify that we're protecting access to
internal mount points like this.
Bug: 22964288
Change-Id: Ic585c4d4381fe51bd764902ef28c38db63b7f2cc
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
avc: denied { sys_chroot } for capability=18 scontext=u:r:vold:s0 tcontext=u:r:vold:s0 tclass=capability permissive=1
avc: denied { mounton } for path="/storage" dev="tmpfs" ino=4155 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir permissive=1
avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=filesystem permissive=0
Bug: 21858077
Change-Id: Ie481d190c5e7a774fbf80fee6e39a980f382967e
Run idmap in its own domain rather than leaving it in installd's domain.
This prevents misuse of installd's permissions by idmap.
zygote also needs to run idmap. For now, just run it in zygote's
domain as it was previously since that is what is done for dex2oat
invocation by zygote. zygote appears to run idmap with system uid
while installd runs it with app UIDs, so using different domains
seems appropriate.
Remove system_file execute_no_trans from both installd and zygote;
this should no longer be needed with explicit labels for dex2oat and
idmap.
Change-Id: If47e2c1326b84c20e94a20f5e699300dce12bdfe
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In order to prevent this bug from happening, we must allow vold cryptfs
commands to complete while a long running mount is underway.
While waiting for vold to be changed to a binder interface, we will simply
create two listeners, one for cryptfs and one for everything else.
Bug: 19197175
Change-Id: I819f6a54c0a232826016823f2fde3adf7be31f9d
(cherry pick from commit 0d22c6cec6)
- Enable logpersistd to write to /data/misc/logd
- Enable logpersistd to read from pstore to help complete any content
lost by reboot disruption
- Enable shell readonly ability logpersistd files in /data/misc/logd
- Enable logcat -f when placed into logd context to act as a
logpersistd (nee logcatd) agent, restrict access to run only in
userdebug or eng
Bug: 19608716
Change-Id: I3209582bc796a1093c325c90068a48bf268e5ab5
- Enable logpersistd to write to /data/misc/logd
- Enable logpersistd to read from pstore to help complete any content
lost by reboot disruption
- Enable shell readonly ability logpersistd files in /data/misc/logd
- Enable logcat -f when placed into logd context to act as a
logpersistd (nee logcatd) agent, restrict access to run only in
userdebug or eng
Bug: 19608716
Change-Id: I3209582bc796a1093c325c90068a48bf268e5ab5
/dev/rtc0 is not the only possible rtc device node, make sure all are given the
rtc_device label.
(cherry-pick of 1b4b3b918b)
Change-Id: Iea6e1271fb054ea7f44860724e04143875867d78
Define an explicit label for /proc/sys/vm/drop_caches and grant to
the various people who need it, including vold which uses it when
performing storage benchmarks.
Also let vold create new directories under it's private storage area
where the benchmarks will be carried out. Mirror the definition of
the private storage area on expanded media.
avc: denied { write } for name="drop_caches" dev="proc" ino=20524 scontext=u:r:vold:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=0
Bug: 21172095
Change-Id: I300b1cdbd235ff60e64064d3ba6e5ea783baf23f
Files on the /oem partition are weird. The /oem partition is an ext4
partition, built in the Android tree using the "oem_image" build target
added in build/ commit b8888432f0bc0706d5e00e971dde3ac2e986f2af. Since
it's an ext4 image, it requires SELinux labels to be defined at build
time. However, the partition is mounted using context=u:object_r:oemfs:s0,
which ignores the labels on the filesystem.
Assign all the files on the /oem image to be oemfs, which is consistent
with how they'll be mounted when /oem is mounted.
Other options would be to use an "unlabeled" label, or try to fix the
build system to not require SELinux labels for /oem images.
(cherrypicked from commit 2025fd1476)
Bug: 20816563
Change-Id: Ibe8d9ff626eace8a2d5d02c3f06290105baa59fe
Files on the /oem partition are weird. The /oem partition is an ext4
partition, built in the Android tree using the "oem_image" build target
added in build/ commit b8888432f0bc0706d5e00e971dde3ac2e986f2af. Since
it's an ext4 image, it requires SELinux labels to be defined at build
time. However, the partition is mounted using context=u:object_r:oemfs:s0,
which ignores the labels on the filesystem.
Assign all the files on the /oem image to be oemfs, which is consistent
with how they'll be mounted when /oem is mounted.
Other options would be to use an "unlabeled" label, or try to fix the
build system to not require SELinux labels for /oem images.
Bug: 20816563
Change-Id: Ibe8d9ff626eace8a2d5d02c3f06290105baa59fe
