The Settings app contains a SystemPropPoker class which notifies every service
on the system that a property has changed.
Address the following denial:
avc: denied { list } for service=NULL scontext=u:r:system_app:s0 tcontext=u:r:servicemanager:s0 tclass=service_manager
Bug: 20762975
Change-Id: I81926e8833c1abcb17a4d49687fc89619b416d6c
Prevent defining any process types without the domain attribute
so that all allow and neverallow rules written on domain are
applied to all processes.
Prevent defining any app process types without the appdomain
attribute so that all allow and neverallow rules written on
appdomain are applied to all app processes.
Change-Id: I4cb565314fd40e1e82c4360efb671b175a1ee389
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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
This enables access to gatekeeperd for anybody who invokes Android
framework APIs. This is necessary because the AndroidKeyStore
abstraction offered by the framework API occasionally communicates
with gatekeeperd from the calling process.
Bug: 20526234
Change-Id: I3362ba07d1a7e5f1c47fe7e9ba6aec5ac3fec747
This enables an optimization of bypassing the FUSE overhead when
migrating emulated storage between volumes.
avc: denied { write } for path="/mnt/expand/6cba9b95-4fc8-4096-b51f-bdb2c007d059/media/obb/.nomedia" dev="dm-0" ino=387843 scontext=u:r:vold:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=file permissive=1
Bug: 19993667
Change-Id: I2bb9aaca50ed988ded6afec6d7fbe190903707e0
This reverts commit c450759e8e.
There was nothing wrong with this change originally --- the companion
change in init was broken.
Bug: http://b/19702273
Change-Id: I9d806f6ac251734a61aa90c0741bec7118ea0387
Users can pick files from vfat devices through the Storage Access
Framework, which are returned through ParcelFileDescriptors. Grant
apps write access to those files. (Direct access to the files on
disk is still controlled through normal filesystem permissions.)
avc: denied { write } for pid=3235 comm="Binder_1" path=2F6D6E742F6D656469615F72772F373243322D303446392F6D656F772F6D79206469722F706963322E706E67 dev="sdb1" ino=87 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:vfat:s0 tclass=file
Bug: 19993667
Change-Id: I24b4d8826f0a35825b2abc63d1cfe851e1c1bfe9
Raw physical storage devices are mounted by vold under /mnt/media_rw
and then wrapped in a FUSE daemon that presents them under /storage.
Normal apps only have access through /storage, but platform apps
(such as ExternalStorageProvider) often bypass the FUSE daemon for
performance reasons.
avc: denied { search } for pid=6411 comm="Binder_1" name="media_rw" dev="tmpfs" ino=6666 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:mnt_media_rw_file:s0 tclass=dir
avc: denied { write } for pid=3701 comm="Binder_2" name="PANO_20131016_162457.jpg" dev="sda1" ino=127 scontext=u:r:platform_app:s0:c522,c768 tcontext=u:object_r:vfat:s0 tclass=file
Bug: 19993667
Change-Id: I66df236eade3ca25a10749dd43d173ff4628cfad
Addresses su denials which occur when mounting filesystems not
defined by policy.
Addresses denials similar to:
avc: denied { mount } for pid=12361 comm="mount" name="/" dev="binfmt_misc" ino=1 scontext=u:r:su:s0 tcontext=u:object_r:unlabeled:s0 tclass=filesystem permissive=1
Change-Id: Ifa0d7c781152f9ebdda9534ac3a04da151f8d78e
We have a /media directory on expanded storage that behaves just
like internal storage, and has a FUSE daemon running above it.
avc: denied { search } for name="expand" dev="tmpfs" ino=3130 scontext=u:r:sdcardd:s0 tcontext=u:object_r:mnt_expand_file:s0 tclass=dir permissive=0
Bug: 19993667
Change-Id: I771ecb8f2808c48ccf4139ac9cfc2a48a2332fec
Provide a default label for binfmt_misc. This is not used by the
core policy, although it may be used in device specific policy.
Bug: 20152930
Change-Id: Id51d69333bfeda40720d0e65e1539fab0b6e1e95
Google Breakpad (crash reporter for Chrome) relies on ptrace
functionality. Without the ability to ptrace, the crash reporter
tool is broken.
Addresses the following denial:
type=1400 audit(1428619926.939:1181): avc: denied { ptrace } for pid=10077 comm="CrRendererMain" scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:r:isolated_app:s0:c512,c768 tclass=process permissive=0
This reverts commit e9623d8fe6.
Bug: 20150694
Bug: https://code.google.com/p/chromium/issues/detail?id=475270
Change-Id: I1727c6a93f10ea6db877687a8f81ec789f9e501f
The current neverallow rule (compile time assertion)
neverallow { domain -gatekeeperd -system_server } gatekeeper_service:service_manager find;
asserts that no rule is present which allows processes other than
system_server from asking servicemanager for a gatekeeperd token.
However, if system_server leaks the token to other processes, it may
be possible for those processes to access gatekeeperd directly, bypassing
servicemanager.
Add a neverallow rule to assert that no process other than system_server
are allowed to make binder calls to gatekeeperd. Even if another process
was to manage to get a binder token to gatekeeperd, it would be useless.
Remove binder_service() from gatekeeperd. The original use of the
binder_service() macro was to widely publish a binder service.
If this macro is present and the calling process has a gatekeeperd
binder token, it's implicitly possible for the following processes
to make a binder call to gatekeeperd:
* all app processes
* dumpstate
* system_server
* mediaserver
* surfaceflinger
Removing binder_service revokes this implicit access.
Add explicit access for system_server to make binder calls to
gatekeeperd.
Add explicit access for gatekeeperd to make calls to keystore.
This was implicitly granted via binder_service() before, but now
needs to be explicit.
Change-Id: I23c1573d04ab670a42660d5922b39eecf4265b66
Settings needs to be able to access it when opening developer options.
Address the following denial:
avc: denied { find } for service=persistent_data_block scontext=u:r:system_app:s0 tcontext=u:object_r:persistent_data_block_service:s0 tclass=service_manager
Bug: 20131472
Change-Id: I85e2334a92d5b8e23d0a75312c9b4b5bf6aadb0b
