It's questionable whether this change is actually needed,
and it only affects one user (who's /data partition was
created oddly).
Revert it for now (in master) to see if we get more reports
of this bug.
Bug: 11149726
Change-Id: I9b5408306b55653b2b9d43e68e7c771b72662649
This fixes the issue where paid apps failed to install via Google
Play with "Package file has a bad manifest" error. The issue appears
to be caused by vold being prevented by SELinux policy from setting
the setgid bit on the ASEC container directory into which the APK is
decrypted. As a result, the APK is not readable to PackageParser.
Bug: 9736808
Change-Id: I07546a9f9caac3de8b720499bd1bf1604edea0fe
This change enables SELinux security enforcement on vold.
For the vold.te file ONLY, this change is conceptually a revert of
77d4731e9d and
50e37b93ac, with the following
additional changes:
1) Removal of "allow vold proc:file write;" and
"allow vold self:capability { sys_boot };". As of system/vold
change adfba3626e76c1931649634275d241b226cd1b9a, vold no longer
performs it's own reboots, so these capabilities are no longer
needed.
2) Addition of the powerctl property, which vold contacts to
tell init to reboot.
3) Removal of "allow vold kernel:system module_request;". As of
CTS commit f2cfdf5c057140d9442fcfeb4e4a648e8258b659, Android
devices no longer ship with loadable modules, hence we don't
require this rule.
4) Removal of "fsetid" from "self:capability". Any setuid / setgid
bits SHOULD be cleared if vold is able to change the permissions
of files. IMHO, it was a mistake to ever include this capability in
the first place.
Testing: As much as possible, I've tested filesystem related
functionality, including factory reset and device encryption.
I wasn't able to test fstrim functionality, which is a fairly
new feature. I didn't see any policy denials in dmesg. It's quite
possible I've missed something. If we experience problems, I
happy to roll back this change.
Bug: 9629920
Change-Id: I683afa0dffe9f28952287bfdb7ee4e0423c2e97a
This prevents denials from being generated by the base policy.
Over time, these rules will be incrementally tightened to improve
security.
Change-Id: I4be1c987a5d69ac784a56d42fc2c9063c402de11
I have no idea what vold is doing when this operation is attempted
(when a full-disk encrypted device is booting up). Thus, I don't know
if there is a better way of restricting the policy.
Change-Id: I537b70b1abb73c36e5abf0357b766292f625e1af
klog_write/init create /dev/__kmsg__ backed by a kernel character
device, keep the file descriptor, and then immediately unlink the
file.
Change-Id: I729d224347a003eaca29299d216a53c99cc3197c
/data/security is another location that policy
files can reside. In fact, these policy files
take precedence over their rootfs counterparts
under certain circumstances. Give the appropriate
players the rights to read these policy files.
Change-Id: I9951c808ca97c2e35a9adb717ce5cb98cda24c41
Two new types are introduced:
sdcard_internal
sdcard_external
The existing type of sdcard, is dropped and a new attribute
sdcard_type is introduced.
The boolean app_sdcard_rw has also been changed to allow for
controlling untrusted_app domain to use the internal and external
sdcards.
Change-Id: Ic7252a8e1703a43cb496413809d01cc6cacba8f5
Creates 2 new types:
- asec_apk_file : files found under /mnt/asec
when the asec images are mounted
- asec_image_file : the actual encrypted apks under
/data/app-asec
Change-Id: I963472add1980ac068d3a6d36a24f27233022832
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
New property_contexts file for property selabel backend.
New property.te file with property type declarations.
New property_service security class and set permission.
Allow rules for setting properties.
