A common source of mistakes when authoring sepolicy is properly
setting up property sets. This is a 3 part step of:
1. Allowing the unix domain connection to the init/property service
2. Allowing write on the property_socket file
3. Allowing the set on class property_service
The macro unix_socket_connect() handled 1 and 2, but could be
confusing for first time policy authors. 3 had to be explicitly
added.
To correct this, we introduce a new macros:
set_prop(sourcedomain, targetprop)
This macro handles steps 1, 2 and 3.
No difference in sediff is expected.
Change-Id: I630ba0178439c935d08062892990d43a3cc1239e
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
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
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
Assign the alarm, appwidget, assetatlas, audio, backup and batterystats services
the appropriate service access levels and move into enforcing.
Bug: 18106000
Change-Id: If3210bb25f3076edfdb6eec36ef6521ace1bd8d7
Move accessibility, account, appops and activity services into enforcing with
app_api_service level of access, with additional grants to mediaserver and
isolated app.
Bug: 18106000
Change-Id: I1d5a79b9223026415f1690e8e9325ec4c270e3dd
system_server no longer has universal service_manager_type permissions and so no
longer needs the auditallow rules therewith associated.
Change-Id: I1e6584c120f6fc464a4bf6b377d9d7ea90441477
This is for the new addAuthToken keystore method from
I7f7647d9a36ea453ec6d62fc84087ca8f76e53dd. These tokens will be used to
authorize keymaster operations. The tokens are HMAC'd and so shouldn't
be fakeable but this is still limited to system_server only.
Change-Id: I3ff46b676ecac8a878d3aa0a25ba9a8b0c5e1f47
Periodically, SELinux denials of the form:
type=1400 audit(0.0:8574): avc: denied { setsched } for comm="system_server" scontext=u:r:system_server:s0 tcontext=u:r:kernel:s0 tclass=process permissive=0
are being generated. These denials come from system_server and other
processes. There's no reason why system_server should be calling
sched_setscheduler() on a kernel thread.
Current belief is that these SELinux denials are a bug in the kernel,
and are being inappropriately triggered.
Revert 2d1650f407. The original reason
for accepting this change was to see if it would fix bug 18085992.
Unfortunately, even after the commit, the bug was still present.
The change had no impact on the bug.
Don't inappropriately grant system_server the ability to minipulate
the scheduling priority of kernel threads.
This reverts commit 2d1650f407.
Change-Id: I59bdf26ad247a02b741af2fa58a18e7e83ef44d8
With the exception of the factory reset protection block device,
don't allow system_server to read or write to any other block
devices. This helps protect against a system->root escalation
when system_server has the ability to directly minipulate raw
block devices / partitions / partition tables.
This change adds a neverallow rule, which is a compile time
assertion that no SELinux policy is written which allows this
access. No new rules are added or removed.
Change-Id: I388408423097ef7cf4950197b79d4be9d666362c
Add neverallow rules to ensure that zygote commands are only taken from
system_server.
Also remove the zygote policy class which was removed as an object manager in
commit: ccb3424639821b5ef85264bc5836451590e8ade7
Bug: 19624279
Change-Id: I1c925d7facf19b3953b5deb85d992415344c4c9f
Allow system server to handle already open app unix_stream_sockets.
This is needed to support system_server receiving a socket
created using socketpair(AF_UNIX, SOCK_STREAM) and
socketpair(AF_UNIX, SOCK_SEQPACKET). Needed for future Android
functionality.
Addresses the following denial:
type=1400 audit(0.0:9): avc: denied { read write } for path="socket:[14911]" dev="sockfs" ino=14911 scontext=u:r:system_server:s0 tcontext=u:r:platform_app:s0:c512,c768 tclass=unix_stream_socket permissive=0
Bug: 19648474
Change-Id: I4644e318aa74ada4d98b7f49a41d13a9b9584f39
Right now, the system_server has the CAP_SYS_MODULE capability. This allows the
system server to install kernel modules. Effectively, system_server is one
kernel module load away from full root access.
Most devices don't need this capability. Remove this capability from
the core SELinux policy. For devices which require this capability,
they can add it to their device-specific SELinux policy without making
any framework code changes.
In particular, most Nexus devices ship with monolithic kernels, so this
capability isn't needed on those devices.
Bug: 7118228
Change-Id: I7f96cc61da8b2476f45ba9570762145778d68cb3
Also formally allow dumpstate access to all services and grant system_server
access to address the following non-system_server_service entries:
avc: granted { find } for service=drm.drmManager scontext=u:r:system_server:s0 tcontext=u:object_r:drmserver_service:s0 tclass=service_manager
avc: granted { find } for service=nfc scontext=u:r:system_server:s0 tcontext=u:object_r:nfc_service:s0 tclass=service_manager
Bug: 18106000
Change-Id: Iad16b36acf44bce52c4824f8b53c0e7731c25602
Revert the tightening of /proc/net access. These changes
are causing a lot of denials, and I want additional time to
figure out a better solution.
Addresses the following denials (and many more):
avc: denied { read } for comm="SyncAdapterThre" name="stats" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="facebook.katana" name="iface_stat_fmt" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="IntentService[C" name="if_inet6" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="dumpstate" name="iface_stat_all" dev="proc" ino=X scontext=u:r:dumpstate:s0 tcontext=u:object_r:proc_net:s0 tclass=file
This reverts commit 0f0324cc82
and commit 99940d1af5
Bug: 9496886
Bug: 19034637
Change-Id: I436a6e3638ac9ed49afbee214e752fe2b0112868
system_server should never be executing dex2oat. This is either
a bug (for example, bug 16317188), or represents an attempt by
system server to dynamically load a dex file, something we don't
want to allow.
This change adds a compile time assertion which will detect
if an allow rule granting this access is ever added.
No new rules are added or deleted as a result of this change.
This neverallow rule is automatically enforced via CTS.
Bug: 16317188
Change-Id: Id783e05d9f48d48642dbb89d9c78be4aae8af70c
Address observed audit logs of the form:
granted { find } for service=XXX scontext=u:r:YYY:s0:c512,c768 tcontext=u:object_r:XXX_service:s0 tclass=service_manager
in order to record existing relationships with services.
Bug: 18106000
Change-Id: I99a68f329c17ba67ebf3b87729b8405bdc925ef4
SELinux domains wanting read access to /proc/net need to
explicitly declare it.
TODO: fixup the ListeningPortsTest cts test so that it's not
broken.
Bug: 9496886
Change-Id: Ia9f1214348ac4051542daa661d35950eb271b2e4
Temporarily give every system_server_service its own
domain in preparation for splitting it and identifying
special services or classes of services.
Change-Id: I81ffbdbf5eea05e0146fd7fd245f01639b1ae0ef
All domains are currently granted list and find service_manager
permissions, but this is not necessary. Pare the permissions
which did not trigger any of the auditallow reporting.
Bug: 18106000
Change-Id: Ie0ce8de2af8af2cbe4ce388a2dcf4534694c994a
Some devices leave "ro.build.fingerprint" undefined at build time,
since they need to build it from the components at runtime.
See 5568772e81
for details.
Allow system_server to set ro.build.fingerprint
Addresses the following denial/error:
avc: denied { set } for property=build.fingerprint scontext=u:r:system_server:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service
init: sys_prop: permission denied uid:1000 name:ro.build.fingerprint
Bug: 18188956
Change-Id: I98b25773904a7be3e3d2926daa82c1d08f9bcc29
