Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.

This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.

This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:

  -user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
  +user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user

For now, this newly introduced label has no usage, so this change
is essentially a no-op.

Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
      filesystem upgrade.

Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837

This is a partial cherry pick of commit 6231b4d9
'Enforce per-app data protections for targetSdk 28+'.

Untrusted_app_27 remains unreachable, but it's existence
prevents future merge conflicts.

Bug: 63897054
Test: build/boot aosp_walleye-userdebug
Change-Id: I64b013874fe87b55f47e817a1279e76ecf86b7c0
Merged-In: I64b013874fe87b55f47e817a1279e76ecf86b7c0
(cherry picked from commit 6231b4d9)

Adds per-app categories to untrusted app domains and their
app data types. Per-app categories are in addition to the
existing per-user categories.

Apps targeting sdk version 28+ will now have the following
characteristics:
Domain: u:r:untrusted_app:s0:c[0-9]+,c[0-9]+,c[0-9],c[0-9]
Data context: u:object_r:app_data_file:s0:c[0-9]+,c[0-9]+,c[0-9],c[0-9]

Whereas apps targeting 27- will look like:
Domain: u:r:untrusted_app_27:s0:c[0-9]+,c[0-9]+
Data context: u:object_r:app_data_file:s0:c[0-9]+,c[0-9]+

To ensure backwards compatibility with previous SDK versions,
the levelFrom=all now enforces categories by dominance instead of
equality. Apps with per-app and per-user categories will continue
to have selinux permissions (but not necessarily unix permissions)
to access app data with only per-user categories, but apps with only
per-user categories will not be able to access the data of apps with
both per-app and per-user categories.

Bug: 63897054
Test: Boot sailfish, run apps, verify no new selinux denials.
Test: cts-tradefed run cts -m CtsSelinuxTargetSdkCurrentTestCases
Test: cts-tradefed run cts -m CtsSelinuxTargetSdk27TestCases
Test: cts-tradefed run cts -m CtsSelinuxTargetSdk25TestCases
Test: adb sideload an OTA and verify that files are correctly labeled.
Change-Id: I64b013874fe87b55f47e817a1279e76ecf86b7c0

In order to support platform changes without simultaneous updates from
non-platform components, the platform and non-platform policies must be
split.  In order to provide a guarantee that policy written for
non-platform objects continues to provide the same access, all types
exposed to non-platform policy are versioned by converting them and the
policy using them into attributes.

This change performs that split, the subsequent versioning and also
generates a mapping file to glue the different policy components
together.

Test: Device boots and runs.
Bug: 31369363
Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317

Divide policy into public and private components.  This is the first
step in splitting the policy creation for platform and non-platform
policies.  The policy in the public directory will be exported for use
in non-platform policy creation.  Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.

Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal.  For now, almost all types and
avrules are left in public.

Test: Tested by building policy and running on device.

Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c

Require equivalence for all write operations.  We were already
doing this for app_data_file as a result of restricting open
rather than read/write, so this makes the model consistent across
all objects and operations.  It also addresses the scenario where
we have mixed usage of levelFrom=all and levelFrom=user for
different apps on the same device where the dominated-by (domby)
relation may not be sufficiently restrictive.

Drop the System V IPC constraints since System V IPC is never allowed
by TE and thus these constraints are dead policy.

Change-Id: Ic06a35030c086e3978c02d501c380889af8d21e0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

This reverts commit 27042f6d.

Managed profiles are represented by new android users which have the ability to
communicate across profiles as governed by an IntentFilter provisioned by the
DevicePolicyManager.  This communication includes reading and writing content
URIs, which is currently obstructed by the mls separation between an owning user
and its managed profile.

Bug: 19444116
Bug: 19525465
Bug: 19540297
Bug: 19592525
Change-Id: Id9a97f24081902bceab5a96ddffd9276d751775b

Addresses the following denial encountered when sharing photos between personal
and managed profiles:

Binder_5: type=1400 audit(0.0:236): avc: denied { read } for path="/data/data/com.google.android.apps.plus/cache/media/3/3bbca5f1bcfa7f1-a-nw" dev="dm-0" ino=467800 scontext=u:r:untrusted_app:s0:c529,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=0

Bug: 19540297
Change-Id: If51108ec5820ca40e066d5ca3e527c7a0f03eca5

Exempt unnamed pipes from the MLS constraints so that they can
be used for cross-user communications when passed over binder or
local socket IPC.

Addresses denials such as:
avc: denied { read } for path="pipe:[59071]" dev="pipefs" ino=59071 scontext=u:r:untrusted_app:s0:c522,c768 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=fifo_file

Bug: 19087939

Change-Id: I77d494c4a38bf473fec05b728eaf253484deeaf8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

This was a legacy of trying to support per-app level isolation
in a compatible manner by blocking direct open but permitting
read/write via passing of open files over Binder or local sockets.
It is no longer relevant and just confusing to anyone trying to use
the mls support for anything else.

Change-Id: I6d92a7cc20bd7d2fecd2c9357e470a30f10967a3
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

Add policy for run-as program and label it in file_contexts.
Drop MLS constraints on local socket checks other than create/relabel
as this interferes with connections with services, in particular for
adb forward.

Change-Id: Ib0c4abeb7cbef559e150a620c45a7c31e0531114
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>