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
Backup service needs to be accessible to all apps to notify the system when
something changes which is being backed-up.
Bug: 18106000
Change-Id: I8f34cca64299960fa45afc8d09110123eb79338b
Chrome's WebSQL implementation works by running sqlite in the
sandboxed renderer process, and sqlite expects to be able to
call flock() on the database file.
Bug: 20134929
Change-Id: Id33a2cd19b779144662056c6f3aba3365b0a2a54
Move the following services from tmp_system_server_service to appropriate
attributes:
network_management
network_score
notification
package
permission
persistent
power
print
processinfo
procstats
Bug: 18106000
Change-Id: I9dfb41fa41cde72ef0059668410a2e9eb1af491c
Commit 85ce2c706e removed hard link
support from create_file_perms, but system_server requires hard
link support for split APKs. Allow it.
Addresses the following denial:
audit(0.0:152): avc: denied { link } for name="base.apk" dev="dm-0" ino=816009 scontext=u:r:system_server:s0 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=0
Steps to reproduce:
1) Find the directory "hellogoogle3.splitapk"
2) adb install-multiple -r hellogoogle3_incremental.apk
3) adb install-multiple -r -p com.google.android.samples.hellogoogle3 native.apk
Expected:
2nd APK installs successfully.
Actual:
2nd APK fails to install.
Change-Id: Ib69fc70dd1c7cd158590db3fd117d6b05acf1cf7
On debuggable builds, system_server can request app heap dumps
by running something similar to the following commands:
% adb shell am set-watch-heap com.android.systemui 1048576
% adb shell dumpsys procstats --start-testing
which will dump the app's heap to /data/system/heapdump. See
framework/base commit b9a5e4ad30c9add140fd13491419ae66e947809d.
Allow this behavior.
Addresses the following denial:
avc: denied { write } for path="/data/system/heapdump/javaheap.bin" dev="dm-0" ino=150747 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
Bug: 20073185
Change-Id: I4b925033a5456867caf2697de6c2d683d0743540
Move the following services from tmp_system_server_service to appropriate
attributes:
jobscheduler
launcherapps
location
lock_settings
media_projection
media_router
media_session
mount
netpolicy
netstats
Bug: 18106000
Change-Id: Ia82d475ec41f658851f945173c968f4abf57e7e1
Required for PackageManagerService to perform restorecon recursively on a
staging dir.
Addresses the following denial:
avc: denied { open } for name="oat" dev="mmcblk0p28" ino=163027 scontext=u:r:system_server:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=dir
Bug: 19550105
Bug: 20087446
Change-Id: I0f6ebb79745091ecb4d6d3dbe92f65606b7469da
