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
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
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
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 services differ in designed access level. Add attributes reflecting this
distinction and label services appropriately. Begin moving access to the newly
labeled services by removing them from tmp_system_server_service into the newly
made system_server_service attribute. Reflect the move of system_server_service
from a type to an attribute by removing access to system_server_service where
appropriate.
Change-Id: I7fd06823328daaea6d6f96e4d6bd00332382230b
Modify create_file_perms and create_dir_perms so it doesn't have
the "link" permission. This permission controls whether hard links
are allowed or not on the given file label. Hard links are a common
source of security bugs, and isn't something we want to support by
default.
Get rid of link_file_perms and move the necessary permissions into
create_file_perms and create_dir_perms. Nobody is using this macro,
so it's pointless to keep it around.
Get rid of unlink on directories. It returns EISDIR if you attempt to
do it, independent of SELinux permissions.
SELinux domains which have a need for hard linking for a particular
file type can add it back to their permission set on an as-needed basis.
Add a compile time assertion (neverallow rule) for untrusted_app.
It's particularly dangerous for untrusted_app to ever have hard
link capabilities, and the neverallow rule will prevent regressions.
Bug: 19953790
Change-Id: I5e9493d2bf5da460d074f0bc5ad8ba7c14dec6e0
Assigning mlstrustedsubject to untrusted_app would undermine
the per-user isolation model being enforced via levelFrom=user
in seapp_contexts and the mls constraints. There is no direct
way to specify a neverallow on attribute assignment, but this
makes use of a particular property of the fork permission to
prevent ever adding mlstrustedsubject to untrusted_app.
A similar restriction for app_data_file and mlstrustedobject
is also important for the same reason, but cannot be expressed
as a neverallow.
Change-Id: I5170cadc55cc614aef0cd5f6491de8f69a4fa2a0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
There were a few instances where allow rules were appended
after the neverallow rules stanza in the .te file. Also
there were some regular allow rules inserted into the CTS-specific
rules section of app.te. Just move the rules as appropriate.
Should be no change in policy.
Change-Id: Iec76f32d4b531d245bbf5dd9f621a71ff5c71f3e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The GMS core feedback agent runs as untrusted_app, and needs
the ability to read /data/anr/traces.txt to report ANR information.
Allow all untrusted_apps to read /data/anr/traces.txt so that GMS core
can access it.
Longer term, we need to move GMS core into it's own domain, but that's
a longer term change.
Addresses the following denial:
W/ndroid.feedback(17825): type=1400 audit(0.0:68004): avc: denied { read } for name="traces.txt" dev="mmcblk0p28" ino=325762 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:anr_data_file:s0 tclass=file
(cherrypick from commit e2547c3bff)
Bug: 18504118
Bug: 18340553
Change-Id: I8b472b6ab7dfe2a73154033e0a088b8e26396fa8
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
Encountered when certinstaller tries to talk to keystore:
ComponentInfo{com.android.certinstaller/com.android.certinstaller.CertInstaller}: java.lang.NullPointerException: Attempt to invoke interface method 'int android.security.IKeystoreService.test()' on a null object reference
Address the following denial:
avc: denied { find } for service=android.security.keystore scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:keystore_service:s0 tclass=service_manager
Bug: 19347232
Change-Id: I35b46da3c78b384cf04216be937c6b5bfa86452d
Relax the neverallow netlink restrictions for app domains.
In particular, some non-AOSP app domains may use netlink sockets
to communicate with a kernel driver.
Continue to neverallow generic netlink sockets for untrusted_app.
The intention here is that only app domains which explicitly need
this functionality should be able to request it.
This change does not add or remove any SELinux rules. Rather, it
just changes SELinux compile time assertions, as well as allowing
this behavior in CTS.
Modify other neverallow rules to use "domain" instead of "self".
Apps shouldn't be able to handle netlink sockets, even those
created in other SELinux domains.
Change-Id: I40de0ae28134ce71e808e5ef4a39779b71897571
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
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
Required for Settings to show name/icon of apps on sd card
(permission copied from untrusted_app)
Also removed duplicate permission (from domain) in untrusted_app
Change-Id: Ib2b3bee4dfb54ad5e45b392fd9bfd65add4a00bf
Netlink uevent sockets are used by the kernel to inform userspace
when certain events occur, for example, when new hardware is added
or removed. This allows userspace to take some action based on those
messages.
Relax the neverallow rule for NETLINK_KOBJECT_UEVENT sockets.
Certain device specific app domains, such as system_app, may have a
need to receive messages from this socket type.
Continue to neverallow NETLINK_KOBJECT_UEVENT sockets for untrusted_app.
These sockets have been the source of rooting attacks in Android
in the past, and it doesn't make sense to expose this to untrusted_apps.
No new SELinux rules are introduced by this change. This is an
adjustment of compile time assertions only.
Bug: 17525863
Change-Id: I3e538dc8096dc23b9678bcd20e3c1e742c21c967
Before actual installation, apks are put in a staging area where they are
scanned by a verifier before completing the install flow. This verifier runs as
a priv-app, which is in the untrusted_app domain. Allow untrusted_app
read-access to these files.
Bug: 16515815
Change-Id: Ifedc12a33b1f53b62f45013e7b253dbc79b02a4e
Further refined auditallow statements associated with
service_manager and added dumpstate to the
service_manager_local_audit_domain.
Change-Id: I2ecc42c8660de6a91f3b4e56268344fbd069ccc0
Add SELinux MAC for the service manager actions list
and find. Add the list and find verbs to the
service_manager class. Add policy requirements for
service_manager to enforce policies to binder_use
macro.
Change-Id: I224b1c6a6e21e3cdeb23badfc35c82a37558f964
Add a neverallow rule that prevents domain from adding a
default_android_service. Add a neverallow rule that prevents
untrusted_app from ever adding a service through
servicemanager.
Change-Id: I963671fb1224147bb49ec8f0b6be0dcc91c23156
NDK r8c and below induced text relocations into every NDK
compiled shared library. (https://code.google.com/p/android/issues/detail?id=23203).
For compatibility, we need to support shared libraries with text relocations
in them.
Addresses the following error / denial:
06-02 13:28:59.495 3634 3634 W linker : libCore.so has text relocations. This is wasting memory and prevents security hardening. Please fix.
<4>[ 57.430677] type=1400 audit(1401740939.756:13): avc: denied { execmod } for pid=3634 comm=".playandlearnhd" path="/data/app-lib/com.adobe.air-2/libCore.so" dev="mmcblk0p28" ino=32745 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
Steps to reproduce:
1) Install Adobe AIR (https://play.google.com/store/apps/details?id=com.adobe.air)
2) Install PBS Parents Play & Learn (https://play.google.com/store/apps/details?id=air.org.pbskids.playandlearnhd)
3) Attempt to run Play & Learn app
Expected:
App runs
Actual:
App crashes with error above.
Bug: 15388851
Change-Id: I88bfd72b2abf2407803da0209d2313c8210c6663
Too many leaky files in that directory. It's a security best practice
to not mount this filesystem, however, we need it mounted for
tracing support. Even though it's mounted, make sure the files aren't
readable.
Bug: 11635985
Change-Id: I6f116c0a03a567a8107a8e07135ce025e51458dd
This change folds the shared_app, media_app, and release_app
domains into untrusted_app, reducing the set of app domains down
to just distinct domains for the fixed UID apps (e.g. system_app, bluetooth,
nfc, radio), a single domain for apps signed by the platform key
(platform_app), and a single domain for all other apps (untrusted_app).
Thus, SELinux only distinguishes when already distinguished by a predefined
Android ID (AID) or by the platform certificate (which get the signature-only
Android permissions and thus may require special OS-level accesses).
It is still possible to introduce specific app domains for specific
apps by adding signer and package stanzas to mac_permissions.xml,
but this can be done on an as-needed basis for specialized apps that
require particular OS-level permissions outside the usual set.
As there is now only a single platform app domains, get rid of the
platformappdomain attribute and platform_app_domain() macro. We used
to add mlstrustedsubject to those domains but drop this since we are not
using MLS in AOSP presently; we can revisit which domains need it if/when
we use MLS.
Since we are dropping the shared, media, and release seinfo entries from
seapp_contexts, drop them from mac_permissions.xml as well. However,
we leave the keys.conf entries in case someone wants to add a signer
entry in the future for specific apps signed by those keys to
mac_permissions.xml.
Change-Id: I877192cca07360c4a3c0ef475f016cc273e1d968
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Coalesce a number of allow rules replicated among multiple
app domains.
Get rid of duplicated rules already covered by domain, appdomain,
or platformappdomain rules.
Split the platformappdomain rules to their own platformappdomain.te
file, document them more fully, and note the inheritance in each
of the relevant *_app.te files.
Generalize isolated app unix_stream_socket rules to all app domains
to resolve denials such as:
avc: denied { read write } for pid=11897 comm="Binder_2" path="socket:[203881]" dev="sockfs" ino=203881 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { getattr } for pid=11990 comm=4173796E635461736B202334 path="socket:[203881]" dev="sockfs" ino=203881 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { getopt } for pid=11990 comm=4173796E635461736B202334 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { read write } for pid=6890 comm="Binder_10" path="socket:[205010]" dev="sockfs" ino=205010 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
avc: denied { getattr } for pid=11990 comm=4173796E635461736B202334 path="socket:[205010]" dev="sockfs" ino=205010 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
avc: denied { getopt } for pid=11990 comm=4173796E635461736B202334 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
Change-Id: I770d7d51d498b15447219083739153265d951fe5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
These same permissions are already allowed via net_domain() and
the rules in net.te.
Change-Id: I4681fb9993258b4ad668333ad7d7102e983b5c2b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The current inline documentation is not entirely accurate and caused
user confusion, e.g. see:
https://groups.google.com/d/msg/android-security-discuss/javBrPT8ius/C4EVEFUu4ZoJ
Try to clarify the meaning of untrusted_app, how app domains are
assigned, and how to move other system apps out of untrusted_app into
a different domain.
Change-Id: I98d344dd078fe9e2738b68636adaabda1f4b3c3a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This new type will allow us to write finer-grained
policy concerning asec containers. Some files of
these containers need to be world readable.
Change-Id: Iefee74214d664acd262edecbb4f981d633ff96ce
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Permissive domains are only intended for development.
When a device launches, we want to ensure that all
permissive domains are in, at a minimum, unconfined+enforcing.
Add FORCE_PERMISSIVE_TO_UNCONFINED to Android.mk. During
development, this flag is false, and permissive domains
are allowed. When SELinux new feature development has been
frozen immediately before release, this flag will be flipped
to true. Any previously permissive domains will move into
unconfined+enforcing.
This will ensure that all SELinux domains have at least a
minimal level of protection.
Unconditionally enable this flag for all user builds.
Change-Id: I1632f0da0022c80170d8eb57c82499ac13fd7858
Various third party apps come with their own binaries that they write out to
their sandbox directories and then execute, e.g.:
audit(1386527439.462:190): avc: denied { execute_no_trans } for pid=1550 comm="Thread-79" path="/data/data/com.cisco.anyconnect.vpn.android.avf/app_bin/busybox" dev="mmcblk0p23" ino=602891 scontext=u:r:untrusted_app:s0:c39,c256 tcontext=u:object_r:app_data_file:s0:c39,c256 tclass=file
While this is not ideal from a security POV, it seems necessary to support for
compatibility with Android today.
Split out the execute-related permissions to a separate allow rule as it
only makes sense for regular files (class file) not other kinds of files
(e.g. fifos, sockets, symlinks), and use the rx_file_perms macro.
Move the rule to untrusted_app only so that we do not permit system apps
to execute files written by untrusted apps.
Change-Id: Ic9bfe80e9b14f2c0be14295c70f23f09691ae66c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add a create_pty() macro that allows a domain to
create and use its own ptys, isolated from the ptys
of any other domain, and use that macro for untrusted_app.
This permits the use of a pty by apps without opening up access
to ptys created by any other domain on the system.
Change-Id: I5d96ce4d1b26073d828e13eb71c48d1e14ce7d6b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
At this point, we still don't understand the root cause of
bug 10290009, or if it's even a real bug. Rollback
29d0d40668 so we an get a device
in this state and figure out the root cause of this problem.
This reverts commit 29d0d40668.
Bug: 10290009
