As an optimization, installd is now moving previously-installed
applications between attached storage volumes. This is effectively
copying to the new location, then deleting the old location.
Since OAT files can now live under /data/app directories, we also
need the ability to relabel those files.
avc: denied { create } for name="base.apk" scontext=u:r:installd:s0 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=1
avc: denied { write } for path="/data/app/com.example.playground-2/base.apk" dev="mmcblk0p16" ino=40570 scontext=u:r:installd:s0 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=1
avc: denied { setattr } for name="base.apk" dev="mmcblk0p16" ino=40570 scontext=u:r:installd:s0 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=1
avc: denied { relabelfrom } for name="base.odex" dev="mmcblk0p16" ino=40574 scontext=u:r:installd:s0 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=1
avc: denied { relabelto } for name="base.odex" dev="mmcblk0p16" ino=40574 scontext=u:r:installd:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file permissive=1
Bug: 19993667, 20275578
Change-Id: I52bb29ed9f57b3216657eb757d78b06eeaf53458
Ensure that AT_SECURE=1 is set when installd executes dex2oat.
LD_PRELOAD is no longer set by init, and installd couldn't see
LD_PRELOAD anyway due to https://android-review.googlesource.com/129971 .
Drop it.
Continuation of commit b00a037992
Change-Id: Icaf08768b3354c6a99dd0f77fef547a706cc96e9
Migrators should be allowed to write to /data/misc/keychain in order
to remove it. Similarly /data/misc/user should be writable by system
apps.
TODO: Revoke zygote's rights to read from /data/misc/keychain on
behalf of some preloaded security classes.
Bug: 17811821
Change-Id: I9e9c6883cff1dca3755732225404909c16a0e547
The following commits added support for runtime resource overlays.
New command line tool 'idmap'
* 65a05fd56dbc9fd9c2511a97f49c445a748fb3c5
Runtime resource overlay, iteration 2
* 48d22323ce39f9aab003dce74456889b6414af55
Runtime resource overlay, iteration 2, test cases
* ad6ed950dbfa152c193dd7e49c369d9e831f1591
During SELinux tightening, support for these runtime resource
overlays was unknowingly broken. Fix it.
This change has been tested by hackbod and she reports that
everything is working after this change. I haven't independently
verified the functionality.
Test cases are available for this by running:
* python frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1c70484011fd9041bec4ef34f93f7a5509906f40
Remove /data/dalvik-cache/profiles from domain. Profiling information
leaks data about how people interact with apps, so we don't want
the data to be available in all SELinux domains.
Add read/write capabilities back to app domains, since apps need to
read/write profiling data.
Remove restorecon specific rules. The directory is now created by
init, not installd, so installd doesn't need to set the label.
Change-Id: Ic1b44009faa30d704855e97631006c4b990a4ad3
This is to accomodate migration to (and ongoing support of) a
new installed-app file topology, in which APK files are placed
in /data/app/$PACKAGE-rev/, there is a canonical-path symlink
/data/app/$PACKAGE/ -> /data/app/$PACKAGE-rev/, and the native
libraries exist not under a top-level /data/app-lib/$PACKAGE-rev
hard directory, but rather under /data/app/$PACKAGE/lib (when
referenced by canonical path).
Change-Id: I4f60257f8923c64266d98aa247bffa912e204fb0
The bugs that motivated bringing back the unlabeled allowall rules,
https://android-review.googlesource.com/#/c/94971/
should be resolved by the following changes:
https://android-review.googlesource.com/#/c/94966/https://android-review.googlesource.com/#/c/96080/
Beyond those changes, installd needs to be able to remove package directories
for apps that no longer exist or have moved (e.g. to priv-app) on upgrades, so
allow it the permissions required for this purpose. vold needs to be able
to chown/chmod/restorecon files in asec containers so allow it the
permissions to do so. system_server tries to access all /data/data
subdirectories so permit it to do so. installd and system_server
read the pkg.apk file before it has been relabeled by vold and therefore
need to read unlabeled files.
Change-Id: I70da7d605c0d037eaa5f3f5fda24f5e7715451dc
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
installd creates /data/.layout_version. Introduce a separate type
for this file (and any other file created by installd under a directory
labeled system_data_file) so that we can allow create/write access by
installd without allowing it to any system data files created by other
processes. This prevents installd from overwriting other system data
files, and ensure that any files it creates will require explicit
rules in order to access.
Change-Id: Id04e49cd571390d18792949c8b2b13b1ac59c016
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Drop rules on data_file_type attribute and replace with
rules on specific types, coalescing with existing rules
where appropriate. Reorganize the rules and try to
annotate the reason for the different rules.
Change-Id: I2d07e7c276a9c29677f67db0ebecfc537c084965
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This was originally to limit the ability to relabel files to
particular types given the ability of all domains to relabelfrom
unlabeled files. Since the latter was removed by
Ied84f8b4b1a0896c1b9f7d783b7463ce09d4807b, this no longer serves
any purpose.
Change-Id: Ic41e94437188183f15ed8b3732c6cd5918da3397
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
91a4f8d4fd created system_app_data_file,
and assigned all system_apps to use this file type. For testing purposes,
our automated testing infrastructure sideloads shared system UID apks.
Installd does not have permission to create the lib symlink, so the
installation fails.
Allow installd to create this symlink.
repro:
adb install AppLaunch.apk
276 KB/s (8414 bytes in 0.029s)
pkg: /data/local/tmp/AppLaunch.apk
Failure [INSTALL_FAILED_INTERNAL_ERROR]
logcat:
05-08 23:16:36.336 605 637 I PackageManager: Copying native libraries to /data/app-lib/vmdl609237490
05-08 23:16:36.338 605 637 W asset : Installing empty resources in to table 0x5e89a368
05-08 23:16:36.359 193 193 W installd: type=1400 audit(0.0:29): avc: denied { create } for name="lib" scontext=u:r:installd:s0 tcontext=u:object_r:system_app_data_file:s0 tclass=lnk_file
05-08 23:16:36.363 193 193 E installd: couldn't symlink directory '/data/data/com.android.tests.applaunch/lib' -> '/data/app-lib/com.android.tests.applaunch-1': Permission denied
05-08 23:16:36.364 605 637 W PackageManager: Failed linking native library dir (user=0)
05-08 23:16:36.364 605 637 W PackageManager: Package couldn't be installed in /data/app/com.android.tests.applaunch-1.apk
Bug: 14659632
Change-Id: Iac4890302cd070aa3f71553af217f343ed7b8bc3
Only keystore itself should be reading / writing it's files.
Remove keystore file access from other SELinux domains, including
unconfined. Add neverallow rules to protect against regressions.
Allow init limited access to recurse into keystore's directory.
Change-Id: I0bb5de7804f4314997c16fac18507933014bcadf
We were using system_data_file for the /data/data directories of
system UID apps to match the DAC ownership of system UID shared with
other system files. However, we are seeing cases where files created
in these directories must be writable by other apps, and we would like
to avoid allowing write to system data files outside of these directories.
So introduce a separate system_app_data_file type and assign it.
This should also help protect against arbitrary writes by system UID
apps to other system data directories.
This resolves the following denial when cropping or taking a user photo
for secondary users:
avc: denied { write } for path="/data/data/com.android.settings/cache/TakeEditUserPhoto2.jpg" dev="mmcblk0p28" ino=82120 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
avc: denied { write } for path="/data/data/com.android.settings/cache/CropEditUserPhoto.jpg" dev="mmcblk0p30" ino=602905 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
Bug: 14604553
Change-Id: Ifa10e3283b07f6bd6ecc16eceeb663edfd756cea
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
I9b8e59e3bd7df8a1bf60fa7ffd376a24ba0eb42f added a profiles
subdirectory to /data/dalvik-cache with files that must be
app-writable. As a result, we have denials such as:
W/Profiler( 3328): type=1400 audit(0.0:199): avc: denied { write } for name="com.google.android.setupwizard" dev="mmcblk0p28" ino=106067 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
W/Profiler( 3328): type=1300 audit(0.0:199): arch=40000028 syscall=322 per=800000 success=yes exit=33 a0=ffffff9c a1=b8362708 a2=20002 a3=0 items=1 ppid=194 auid=4294967295 uid=10019 gid=10019 euid=10019 suid=10019 fsuid=10019 egid=10019 sgid=10019 fsgid=10019 tty=(none) ses=4294967295 exe="/system/bin/app_process" subj=u:r:untrusted_app:s0 key=(null)
W/auditd ( 286): type=1307 audit(0.0:199): cwd="/"
W/auditd ( 286): type=1302 audit(0.0:199): item=0 name="/data/dalvik-cache/profiles/com.google.android.setupwizard" inode=106067 dev=b3:1c mode=0100664 ouid=1012 ogid=50019 rdev=00:00 obj=u:object_r:dalvikcache_data_file:s0
We do not want to allow untrusted app domains to write to the
existing type on other /data/dalvik-cache files as that could be used
for code injection into another app domain, the zygote or the system_server.
So define a new type for this subdirectory. The restorecon_recursive /data
in init.rc will fix the labeling on devices that already have a profiles
directory created. For correct labeling on first creation, we also need
a separate change to installd under the same change id.
Bug: 13927667
Change-Id: I4857d031f9e7e60d48b8c72fcb22a81b3a2ebaaa
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Old Android kernels (e.g. kernel/goldfish android-2.6.29 commit 2bda29)
fell back to a CAP_SYS_ADMIN check even before checking uids if the cgroup
subsystem did not define its own can_attach handler. This doesn't appear
to have ever been the case of mainline, and is not true of the 3.4 Android
kernels. So we no longer need to dontaudit sys_admin to avoid log noise.
Change-Id: I3822600a06c242764a94f9b67d9fcd6f599d3453
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Ability to relabel from/to any of the types that can be assigned
to /data/data directories as per seapp_contexts type= assignments.
Change-Id: I05e8b438950ddb908e46c9168ea6ee601e6d674f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This appears to have been created to allow untrusted_app to
access DownloadProvider cache files without needing to allow
open access to platform_app_data_file. Now that platform_app_data_file
is gone, there is no benefit to having this type.
Retain a typealias for download_file to app_data_file until
restorecon /data/data support is in place to provide compatibility.
This change depends on:
https://android-review.googlesource.com/#/c/87801/
Change-Id: Iab3c99d7d5448bdaa5c1e03a98fb6163804e1ec4
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The original concept was to allow separation between /data/data/<pkgdir>
files of "platform" apps (signed by one of the four build keys) and
untrusted apps. But we had to allow read/write to support passing of
open files via Binder or local socket for compatibilty, and it seems
that direct open by pathname is in fact used in Android as well,
only passing the pathname via Binder or local socket. So there is no
real benefit to keeping it as a separate type.
Retain a type alias for platform_app_data_file to app_data_file until
restorecon /data/data support is in place to provide compatibility.
Change-Id: Ic15066f48765322ad40500b2ba2801bb3ced5489
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
During removing cache data using Zipper application, I found violation logs.
avc: denied { write } for pid=198 comm="installd" name="cache" dev="mmcblk0p29" ino=81680 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=dir
avc: denied { remove_name } for pid=198 comm="installd" name="downloadfile.apk" dev="mmcblk0p29" ino=82247 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=dir
avc: denied { unlink } for pid=198 comm="installd" name="downloadfile.apk" dev="mmcblk0p29" ino=82247 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=file
Reproduction path is like below
1. Downloading Zipper application from Google Play (I used Zipper 1.9.9.2)
2. Clicking option and clicking "removing cache" button
3. Select "yes"
4. Violation show up
Change-Id: I7993f1d20e3aa4c3e19c4aba9b4bef6760831a87
bluetooth, nfc, radio and shell are not explicitly declared
in installd.te. This prevents applications in those group
from upgrading by "adb install -r".
You can reproduce the issue by following step:
1. adb pull /system/priv-app/Shell.apk
2. adb install -r Shell.apk
3. install failed with the error log blow
[Error in logcat]
E/installd( 338): couldn't symlink directory '/data/data/com.android.shell/lib' -> '/data/app-lib/com.android.shell-1': Permission denied
E/installd( 338): couldn't symlink directory '/data/data/com.android.shell/lib' -> '/data/app-lib/Shell': Permission denied
[Error in dmesg]
<5>[ 112.053301] type=1400 audit(1387412796.071:10): avc: denied { create } for pid=337 comm="installd" name="lib" scontext=u:r:installd:s0 tcontext=u:object_r:shell_data_file:s0 tclass=lnk_file
This operation fails only if the app belongs to any of the
groups specified in the commit title.
Change-Id: I7572df9fb6e471fad34f61137f0eeeda4c82659d
The emulator has been upgraded to ext4, which was the root cause
of bug 9685803. See https://code.google.com/p/android/issues/detail?id=38561 .
As a result, we can reenable installd protections.
This reverts commit 201cfae474.
Bug: 9685803
Change-Id: I4ed47f7aeaef4aac504e13c2ae23fb416e4e6e49
For unlabeled files, revert to DAC rules. This is for backwards
compatibility, as files created before SELinux was in place may
not be properly labeled.
Over time, the number of unlabeled files will decrease, and we can
(hopefully) remove this rule in the future.
To prevent inadvertantly introducing the "relabelto" permission, add
a neverallow domain, and add apps which have a legitimate need to
relabel to this domain.
Bug: 9777552
Change-Id: I71b0ff8abd4925432062007c45b5be85f6f70a88
This change enables SELinux security enforcement on the installd
process.
For the installd.te file only, this change is equivalent to reverting
the following commits:
* 50e37b93ac
* 77d4731e9d
No other changes were required.
Testing: As much as possible, I've tested that package installation
works, from both adb and via Android market. There were no denials
in the kernel dmesg log, and everything appears to be working correctly.
It's quite possible I've missed something. If we experience problems,
I'm happy to roll back this change.
Bug: 9662644
Change-Id: Id93d4ee7b517dfa28c9a0b1d45d936b56892ac0a
This prevents denials from being generated by the base policy.
Over time, these rules will be incrementally tightened to improve
security.
Change-Id: I4be1c987a5d69ac784a56d42fc2c9063c402de11
/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
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>
