Bug: 18068520
Bug: 21852542
Change-Id: I080547c61cbaacb18e003a9b2366e2392a6521ff

/proc/iomem is currently given the proc label but contains system information
which should not be available to all processes.

Bug: 22008387
Change-Id: I4f1821f40113a743ad986d13d8d130ed8b8abf2f

- Enable logpersistd to write to /data/misc/logd
- Enable logpersistd to read from pstore to help complete any content
  lost by reboot disruption
- Enable shell readonly ability logpersistd files in /data/misc/logd
- Enable logcat -f when placed into logd context to act as a
  logpersistd (nee logcatd) agent, restrict access to run only in
  userdebug or eng

Bug: 19608716
Change-Id: I3209582bc796a1093c325c90068a48bf268e5ab5

Bug: 19483574
Change-Id: I7e4c0cf748d2b216dcb3aede3803883552b58b64

Use a more specific label for /data/misc/gatekeeper

Rearrange some other rules.

Change-Id: Ib634e52526cf31a8f0a0e6d12bbf0f69dff8f6b5

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

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

Expanded storage supports a subset of the features of the internal
data partition.  Mirror that policy for consistency.  vold is also
granted enough permissions to prepare initial directories.

avc: denied { write } for name="ext" dev="tmpfs" ino=3130 scontext=u:r:vold:s0 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1
avc: denied { add_name } for name="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" scontext=u:r:vold:s0 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1
avc: denied { create } for name="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" scontext=u:r:vold:s0 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1
avc: denied { setattr } for name="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" dev="tmpfs" ino=7243 scontext=u:r:vold:s0 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1
avc: denied { mounton } for path="/mnt/ext/57f8f4bc-abf4-655f-bf67-946fc0f9f25b" dev="tmpfs" ino=7243 scontext=u:r:vold:s0 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1

avc: denied { getattr } for path="/mnt/ext" dev="tmpfs" ino=3130 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:mnt_ext_file:s0 tclass=dir permissive=1

avc: denied { setattr } for name="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" dev="tmpfs" ino=4471 scontext=u:r:vold:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
avc: denied { getattr } for path="/mnt/expand/57f8f4bc-abf4-655f-bf67-946fc0f9f25b/media" dev="dm-0" ino=145153 scontext=u:r:vold:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=dir permissive=1

avc: denied { rmdir } for name="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" dev="tmpfs" ino=6380 scontext=u:r:vold:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1

avc: denied { create } for name="tmp" scontext=u:r:vold:s0 tcontext=u:object_r:shell_data_file:s0 tclass=dir permissive=1
avc: denied { setattr } for name="tmp" dev="dm-0" ino=72578 scontext=u:r:vold:s0 tcontext=u:object_r:shell_data_file:s0 tclass=dir permissive=1

Bug: 19993667
Change-Id: I73c98b36e7c066f21650a9e16ea82c5a0ef3d6c5

Creates new directory at /data/misc/vold for storing key material
on internal storage.  Only vold should have access to this label.

Change-Id: I7f2d1314ad3b2686e29e2037207ad83d2d3bf465

An upcoming platform release is redesigning how external storage
works.  At a high level, vold is taking on a more active role in
managing devices that dynamically appear.

This change also creates further restricted domains for tools doing
low-level access of external storage devices, including sgdisk
and blkid.  It also extends sdcardd to be launchable by vold, since
launching by init will eventually go away.

For compatibility, rules required to keep AOSP builds working are
marked with "TODO" to eventually remove.

Slightly relax system_server external storage rules to allow calls
like statfs().  Still neverallow open file descriptors, since they
can cause kernel to kill us.

Here are the relevant violations that this CL is designed to allow:

avc: denied { search } for name="user" dev="tmpfs" ino=7441 scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { getattr } for path="/mnt/user/0" dev="tmpfs" ino=6659 scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { write } for name="user" dev="tmpfs" ino=6658 scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { add_name } for name="10" scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { create } for name="10" scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { setattr } for name="10" dev="tmpfs" ino=11348 scontext=u:r:zygote:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { search } for name="/" dev="tmpfs" ino=3131 scontext=u:r:zygote:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { getattr } for path="/storage" dev="tmpfs" ino=6661 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { getattr } for path="/storage/self" dev="tmpfs" ino=6659 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { getattr } for path="/storage" dev="tmpfs" ino=6661 scontext=u:r:untrusted_app:s0:c522,c768 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { getattr } for path="/storage/self" dev="tmpfs" ino=11348 scontext=u:r:untrusted_app:s0:c522,c768 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { getattr } for path="/storage" dev="tmpfs" ino=6661 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { read } for name="/" dev="tmpfs" ino=6661 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { open } for name="/" dev="tmpfs" ino=6661 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { search } for name="/" dev="tmpfs" ino=6661 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { write } for name="data" dev="tmpfs" ino=11979 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { add_name } for name="com.google.android.music" scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { create } for name="com.google.android.music" scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { use } for path="socket:[8297]" dev="sockfs" ino=8297 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { read write } for path="socket:[8297]" dev="sockfs" ino=8297 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=netlink_kobject_uevent_socket
avc: denied { read } for path="pipe:[8298]" dev="pipefs" ino=8298 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=fifo_file
avc: denied { write } for path="pipe:[8298]" dev="pipefs" ino=8298 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=fifo_file
avc: denied { mounton } for path="/storage/emulated" dev="tmpfs" ino=8913 scontext=u:r:sdcardd:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { getattr } for path="/storage" dev="tmpfs" ino=7444 scontext=u:r:system_server:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { getattr } for path="/storage/self/primary" dev="tmpfs" ino=7447 scontext=u:r:system_server:s0 tcontext=u:object_r:storage_file:s0 tclass=lnk_file
avc: denied { read } for name="primary" dev="tmpfs" ino=7447 scontext=u:r:system_server:s0 tcontext=u:object_r:storage_file:s0 tclass=lnk_file
avc: denied { getattr } for path="/mnt/user" dev="tmpfs" ino=7441 scontext=u:r:system_server:s0 tcontext=u:object_r:mnt_user_file:s0 tclass=dir
avc: denied { read } for name="disk:179,128" dev="tmpfs" ino=3224 scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { open } for path="/dev/block/vold/disk:179,128" dev="tmpfs" ino=3224 scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { getattr } for path="/dev/block/vold/disk:179,128" dev="tmpfs" ino=3224 scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { read } for name="/" dev="fuse" ino=0 scontext=u:r:vold:s0 tcontext=u:object_r:fuse:s0 tclass=dir
avc: denied { open } for path="/storage/public:81F3-13EC" dev="fuse" ino=0 scontext=u:r:vold:s0 tcontext=u:object_r:fuse:s0 tclass=dir
avc: denied { write } for name="data" dev="fuse" ino=2 scontext=u:r:vold:s0 tcontext=u:object_r:fuse:s0 tclass=dir
avc: denied { add_name } for name="com.google.android.googlequicksearchbox" scontext=u:r:vold:s0 tcontext=u:object_r:fuse:s0 tclass=dir
avc: denied { create } for name="com.google.android.googlequicksearchbox" scontext=u:r:vold:s0 tcontext=u:object_r:fuse:s0 tclass=dir
avc: denied { getattr } for path="/dev/block/vold/public:179,129" dev="tmpfs" ino=16953 scontext=u:r:blkid:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { read } for name="public:179,129" dev="tmpfs" ino=16953 scontext=u:r:blkid:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { open } for path="/dev/block/vold/public:179,129" dev="tmpfs" ino=16953 scontext=u:r:blkid:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { ioctl } for path="/dev/block/vold/public:179,129" dev="tmpfs" ino=16953 scontext=u:r:blkid:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file
avc: denied { use } for path="pipe:[3264]" dev="pipefs" ino=3264 scontext=u:r:sgdisk:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { use } for path="pipe:[3264]" dev="pipefs" ino=3264 scontext=u:r:sgdisk:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { search } for name="block" dev="tmpfs" ino=2494 scontext=u:r:sgdisk:s0 tcontext=u:object_r:block_device:s0 tclass=dir
avc: denied { use } for path="pipe:[4200]" dev="pipefs" ino=4200 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { use } for path="pipe:[4200]" dev="pipefs" ino=4200 scontext=u:r:sdcardd:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { search } for name="/" dev="tmpfs" ino=3131 scontext=u:r:sdcardd:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
avc: denied { search } for name="media_rw" dev="tmpfs" ino=3127 scontext=u:r:sdcardd:s0 tcontext=u:object_r:mnt_media_rw_file:s0 tclass=dir
avc: denied { getattr } for path="pipe:[3648]" dev="pipefs" ino=3648 scontext=u:r:blkid:s0 tcontext=u:r:vold:s0 tclass=fifo_file
avc: denied { use } for path="/dev/pts/12" dev="devpts" ino=15 scontext=u:r:fsck:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { use } for path="/dev/pts/12" dev="devpts" ino=15 scontext=u:r:fsck:s0 tcontext=u:r:vold:s0 tclass=fd
avc: denied { use } for path="pipe:[4182]" dev="pipefs" ino=4182 scontext=u:r:fsck:s0 tcontext=u:r:vold:s0 tclass=fd

Change-Id: Idf3b8561baecf7faa603fac5ababdcc5708288e1

Add selinux rules to allow file level encryption to work

Change-Id: I1e4bba23e99cf5b2624a7df843688fba6f3c3209

- allow access for /data/system/packages.xml.
- deprecate access to /dev/logd_debug (can use /dev/kmsg for debugging)
- allow access to /dev/socket/logd for 'logd --reinit'

Bug: 19681572
Change-Id: Iac57fff1aabc3b061ad2cc27969017797f8bef54

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 0f0324cc
and commit 99940d1a

Bug: 9496886
Bug: 19034637
Change-Id: I436a6e3638ac9ed49afbee214e752fe2b0112868

allow the bootchart to create dir and files at init,
also allow user to create the stop and start file under
/data/bootchart directory to start and stop bootchart

Change-Id: Icfee8dcd17366383eef00fbe3139744bf4427a6b
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>

Commit a833763b enabled per-user
isolation, which requires that any files / processes which cross
user boundaries be marked with the mlstrustedsubject attribute.

system_app_data_file, used for storing a user's profile photos,
is not marked as such. As a result, users are unable to add profile
photos.

Addresses the following denial:

  avc: denied { write } for path="/data/data/com.android.settings/cache/TakeEditUserPhoto2.jpg" dev="mmcblk0p28" ino=82184 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=file

Steps to reproduce:

  1.Flash & Factory the Deb device with tip-of-tree build
  2.Go to 'Settings-Users'
  3.Under users&profiles,click on Owner to add profile photo.
  4.Select 'Choose photo from Gallery' and select a photo.
  5.Then click the 'Done' button.
  6.Device showed the message as 'Unable to save the photo edits'.

OBSERVED RESULTS:
  Unable to add user's profile photo id. This issue is coming for all
  users(Restricted user,second user)also.

EXPECTED RESULTS:
  Device should allow to add profile photo id.

Bug: 19170844
Change-Id: If657dc09dd391e63ca85320f9cc1728580e51a15

external/sepolicy commit 99940d1a
(https://android-review.googlesource.com/123331) removed /proc/net
access from domain.te.

Around the same time, system/core commit
9a20e67fa62c1e0e0080910deec4be82ebecc922
(https://android-review.googlesource.com/123531) was checked in.
This change added libnl as a dependency of libsysutils.

external/libnl/lib/utils.c has a function called get_psched_settings(),
which is annotated with __attribute__((constructor)). This code
gets executed when the library is loaded, regardless of whether or
not other libnl code is executed.

By adding the libnl dependency, even code which doesn't use the
network (such as vold and logd) ends up accessing /proc/net/psched.

For now, allow this behavior. However, in the future, it would be
better to break this dependency so the additional code isn't loaded
into processes which don't need it.

Addresses the following denials:

  avc: denied { read } for  pid=148 comm="logd" name="psched" dev="proc" ino=4026536508 scontext=u:r:logd:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0
  avc: denied { read } for pid=152 comm="vold" name="psched" dev="proc" ino=4026536508 scontext=u:r:vold:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0
  avc: denied { read } for pid=930 comm="wpa_supplicant" name="psched" dev="proc" ino=4026536508 scontext=u:r:wpa:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0

Bug: 19079006
Change-Id: I1b6d2c144534d3f70f0028ef54b470a75bace1cf

adbd writes debugging information to /data/adb
when persist.adb.trace_mask is set. Allow it.

Bug: https://code.google.com/p/android/issues/detail?id=72895

(cherry picked from commit 973877db)

Change-Id: Ida2e0257c97941ab33ccdab59eb2cde95dca344f

(cherrypick of commit d7e004eb)

Change-Id: I7993698ac96f21db0039681275280dbd43ff61ba

Change-Id: I7993698ac96f21db0039681275280dbd43ff61ba

adbd writes debugging information to /data/adb
when persist.adb.trace_mask is set. Allow it.

Bug: https://code.google.com/p/android/issues/detail?id=72895
Change-Id: Ia5af09045e9f72a95325b429c30a5ae78e104bdc

Migrators should be allowed to write to /data/misc/keychain in order
to remove it. Similarly /data/misc/user should be writable by system
apps.

TODO: Revoke zygote's rights to read from /data/misc/keychain on
behalf of some preloaded security classes.

Bug: 17811821
Change-Id: I9e9c6883cff1dca3755732225404909c16a0e547

Resolves denials such as:
avc:  denied  { write } for  pid=1546 comm="Binder_1" name="/" dev="dm-0" ino=2 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:asec_apk_file:s0 tclass=dir

This is required to install a forward-locked app.

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

In order to support the new goldfish service domains in
a change with the same Change-Id for the build project, we need
the following changes in external/sepolicy:
- /system/bin/logcat needs its own type so that it can be used as an
entrypoint for the goldfish-logcat service.  A neverallow rule prevents
us from allowing entrypoint to any type not in exec_type.
- The config. and dalvik. property namespaces need to be labeled
with something other than default_prop so that the qemu-props
service can set them.  A neverallow rule prevents us from allowing
qemu-props to set default_prop.

We allow rx_file_perms to logcat_exec for any domain that
was previously allowed read_logd() as many programs will read
the logs by running logcat.  We do not do this for all domains
as it would violate a neverallow rule on the kernel domain executing
any file without transitioning to another domain, and as we ultimately
want to apply the same restriction to the init domain (and possibly others).

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

Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.

To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.

This change:

1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.

Addresses the following denial:

  avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file

Bug: 17671501

(cherry picked from commit 2de02877)

Change-Id: I2c2366bee4fe365288d14bca9778d23a43c368cb

Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.

To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.

This change:

1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.

Addresses the following denial:

  avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file

Bug: 17671501
Change-Id: Ib70624fba2baeccafbc0a41369833f76b976ee20

dumpstate and lmkd need to act on apps running at any level.

Various file types need to be writable by apps running at any
level.

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

When using MLS (i.e. enabling levelFrom= in seapp_contexts),
certain domains and types must be exempted from the normal
constraints defined in the mls file.  Beyond the current
set, adbd, logd, mdnsd, netd, and servicemanager need to
be able to read/write to any level in order to communicate
with apps running with any level, and the logdr and logdw
sockets need to be writable by apps running with any level.

This change has no impact unless levelFrom= is specified in
seapp_contexts, so by itself it is a no-op.

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

Fix two neverallow rules that yield Invalid SELinux context
warnings from the CTS SELinuxTest.

For transitions from app domains, we only need to check
{ domain -appdomain } (i.e. domains other than app domains),
not ~appdomain (i.e. all types other than app domains).  Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing since the target class is process,
and such contexts are invalid.

For keeping file_type and fs_type exclusive, we only need to
check associate permission, not all filesystem permissions, as
only associate takes a file type as the source context.  Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing filesystem permissions other than
associate, since the source of such checks is normally a process
context.

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

(cherry picked from commit 21ada26d)

Change-Id: I3346584da9b89f352864dcc30dde06d6bf42e98e

Fix two neverallow rules that yield Invalid SELinux context
warnings from the CTS SELinuxTest.

For transitions from app domains, we only need to check
{ domain -appdomain } (i.e. domains other than app domains),
not ~appdomain (i.e. all types other than app domains).  Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing since the target class is process,
and such contexts are invalid.

For keeping file_type and fs_type exclusive, we only need to
check associate permission, not all filesystem permissions, as
only associate takes a file type as the source context.  Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing filesystem permissions other than
associate, since the source of such checks is normally a process
context.

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

Change-Id: Idcd252e39b2c4829201c93b6c99cf368adcb405e

Rename sdcard_internal/external types to fuse and vfat
respectively to make it clear that they are assigned to any
fuse or vfat filesystem by default (absent a context= mount option)
and do not necessarily represent the SDcard.

The sdcard_type attribute is still assigned to both types and
can still be used in allow rules to permit access to either the
internal or external SDcard.

Define type aliases for the old names to preserve compatibility
on policy reload and for device-specific policies that may not yet
be updated.

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

This will be used to populate rt_tables (a mapping from routing table numbers to
table names) that's read by the iproute2 utilities.

Change-Id: I69deb1a64d5d6647470823405bf0cc55b24b22de

The following commits added support for runtime resource overlays.

  New command line tool 'idmap'
  * 65a05fd56dbc9fd9c2511a97f49c445a748fb3c5
  Runtime resource overlay, iteration 2
  * 48d22323ce39f9aab003dce74456889b6414af55
  Runtime resource overlay, iteration 2, test cases
  * ad6ed950dbfa152c193dd7e49c369d9e831f1591

During SELinux tightening, support for these runtime resource
overlays was unknowingly broken. Fix it.

This change has been tested by hackbod and she reports that
everything is working after this change. I haven't independently
verified the functionality.

Test cases are available for this by running:
  * python frameworks/base/core/tests/overlaytests/testrunner.py

Change-Id: I1c70484011fd9041bec4ef34f93f7a5509906f40

Several device-specific policy changes with the same Change-Id
also add this attribute to device-specific types.

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

(cherry picked from commit d2503ba8)

Change-Id: I08a718ba0d91641de720440e16abc0a04f5ec5a5

Several device-specific policy changes with the same Change-Id
also add this attribute to device-specific types.

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

It's a bug to have a type with both the file_type and fs_type
attribute. A type should be declared with either file_type,
or fs_type, but not both.

Create a neverallow rule which detects this situation. This works
because we have the following allow rule:

  allow fs_type self:filesystem associate;

If a type is a file_type and an fs_type, the associate allow rule
will conflict with this neverallow rule.

Not sure if this is the cleanest way to accomplish this, but it
seems to work.

Change-Id: Ida387b1df260efca15de38ae7a66ed25e353acaa

Right now usbfs doesn't have any labels, generating the
following kernel warnings:

<7>[    3.009582] SELinux: initialized (dev usbfs, type usbfs), not configured for labeling

and the occasional SELinux unlabeled auditallow logs:

<4>[  285.579254] type=1400 audit(1402010345.094:16): avc: granted { search } for pid=371 comm="qcks" name="/" dev="usbfs" ino=15794 scontext=u:r:kickstart:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
<4>[  285.632354] type=1400 audit(1402010345.154:18): avc: granted { search } for pid=371 comm="qcks" name="001" dev="usbfs" ino=15796 scontext=u:r:kickstart:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir

Make sure usbfs is assigned via genfscon

Change-Id: I7191f2584014ba55a3c3a98e7efd0350dc958782

/data/property is only accessible by root and is used by the init
property service for storing persistent property values.  Create
a separate type for it and only allow init to write to the directory
and files within it.  Ensure that we do not allow access to other domains
in future changes or device-specific policy via a neverallow rule.

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

Define a domain and appropriate access rules for shared RELRO files
(used for loading the WebView native library). Any app is permitted to
read the files as they are public data, but only the shared_relro
process is permitted to create/update them.

Bug: 13005501
Change-Id: I9d5ba9e9eedb9b8c80fe6f84a3fc85a68553d52e

(cherry picked from commit 7d51096d4106a441a15741592d9ccdd0bfaca907)

Change-Id: Ib6198e19dbc306521a26fcecfdf6e8424d163fc9