Rather then allowing open,read,write to raw block devices, one
should relabel it to something more specific.

vold should be re-worked so we can drop it from this assert.

Change-Id: Ie891a9eaf0814ea3878d32b18b4e9f4d7dac4faf

Commit Icc5febc5fe5a7cccb90ac5b83e6289c2aa5bf069
introduced a new error check for non existent
BOARD_SEPOLICY_UNION files. Need an update to
the docs describing the change.

Change-Id: If96c9046565b05e0811ab2d526ae12a3b8b90bf0
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>

We can read any efs_files, but can't look in the directory
containing them. Allow it.

Without this patch, high resolution movie playback is broken.

Addresses the following denial:

[  276.780046] type=1400 audit(1391105234.431:5): avc:  denied  { search } for  pid=125 comm="drmserver" name="/" dev="mmcblk0p1" ino=2 scontext=u:r:drmserver:s0 tcontext=u:object_r:efs_file:s0 tclass=dir

Bug: 12819852

Change-Id: Ie9d13a224cef5e229de1bdb78d605841ed387a21

Linux defines two capabilities for Mandatory Access Control (MAC)
security modules, CAP_MAC_OVERRIDE (override MAC access restrictions)
and CAP_MAC_ADMIN (allow MAC configuration or state changes).
SELinux predates these capabilities and did not originally use them,
but later made use of CAP_MAC_ADMIN as a way to control the ability
to set security context values unknown to the currently loaded
SELinux policy on files.  That facility is used in Linux for e.g.
livecd creation where a file security context that is being set
on a generated filesystem is not known to the build host policy.
Internally, files with such labels are treated as having the unlabeled
security context for permission checking purposes until/unless the
context is later defined through a policy reload.

CAP_MAC_OVERRIDE is never checked by SELinux, so it never needs
to be allowed.  CAP_MAC_ADMIN is only checked if setting an
unknown security context value; the only legitimate use I can see
in Android is the recovery console, where a context may need to be set
on /system that is not defined in the recovery policy.

Remove these capabilities from unconfined domains, allow
mac_admin for the recovery domain, and add neverallow rules.

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

This was originally used for the /data/fdAlbum
file. Device specific policy properly labels the
file as camera_data_file either during its
initial creation (type_transition rule) or with
a single restorecon call in the respective init.*.rc
file.

Change-Id: Ie953dcf4c40883db09cfb4ffec2a42e8ccd6344c
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>

See http://code.google.com/p/android/issues/detail?id=65339



Further denials were observed in testing and allowed as well.

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

Added a new check to make sure that all listed
BOARD_SEPOLICY_UNION files are located somewhere
in the listed BOARD_SEPOLICY_DIRS locations. The
build will error out otherwise.

Change-Id: Icc5febc5fe5a7cccb90ac5b83e6289c2aa5bf069
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>

Allow bluetooth to handle media_rw_data_file file descriptors
sent to it from other processes. Without this, bluetooth
picture / video sharing is broken.

Steps to reproduce:
1. Take few pictures
2. launch gallery and choose a picture/video and click on share and choose
   available BT device and share

Other info from bug report:

- Bluetooth process queries media content provider for a file descriptor,
  with an Uri like "content://media/external/images/media/69"
- Media server resolves the uri to a file on the filesystem, in the case of
  Gallery at "/storage/emulated/0/DCIM/Camera/IMG_20140128_141656.jpg"
- Media server returns the FD over binder to bluetooth
- Bluetooth is unable to read the file backed by the file descriptor.

Fixes Denial:

<5>[  821.040286] type=1400 audit(1390952161.805:11): avc:  denied  { read } for  pid=1348 comm="Binder_3" path="/data/media/0/DCIM/Camera/IMG_20140128_141656.jpg" dev="mmcblk0p23" ino=236246 scontext=u:r:bluetooth:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=file

Bug: 12457805
Change-Id: I1423d06a98416ae4ab19508f0d005a6353acadc4

Creation of directories on /sdcard was not allowed for the
shell user. Fixed.

Steps to reproduce:

adb shell
cd /sdcard
mkdir foo

Addresses the following denial:

<5>[  446.361215] type=1400 audit(13427374.189:13): avc:  denied  { create } for  pid=3264 comm="mkdir" name="foo" scontext=u:r:shell:s0 tcontext=u:object_r:sdcard_internal:s0 tclass=dir

Bug: 12778268
Change-Id: I5a91b7581fe7e97fbf3caeed9fdf74981e49c58e

Healthd has an optional "charger" mode. The device boots into a
minimally running mode, and healthd displays the battery indicator.

Without this patch, when a manta device boots into charger mode,
the screen will never turn off and the battery indicator will not move.

From reviewing the healthd code, it looks like this may affect lots
of devices, not just manta. I'm adding this change to the generic
policy.

Steps to reproduce:

1) Make sure the device is unplugged.
2) Boot into a normal system.
3) Shutdown the system normally using the power button.
4) After shutdown, plugin the power cord.
5) Device will boot into charger mode. Battery icon will display.
6) Press the button to reboot into a normal mode.
7) Examine /proc/last_kmsg and look for denials.

Addresses the following denials:

[    3.908457] type=1400 audit(1390866386.620:3): avc:  denied  { read write } for  pid=98 comm="charger" name="fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[    3.909085] type=1400 audit(1390866386.620:4): avc:  denied  { open } for  pid=98 comm="charger" name="fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[    3.909749] type=1400 audit(1390866386.620:5): avc:  denied  { ioctl } for  pid=98 comm="charger" path="/dev/graphics/fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[    4.889857] type=1400 audit(1390866387.605:6): avc:  denied  { read } for  pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[    4.890873] type=1400 audit(1390866387.605:7): avc:  denied  { open } for  pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[    4.891949] type=1400 audit(1390866387.605:8): avc:  denied  { search } for  pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[    4.892677] type=1400 audit(1390866387.605:9): avc:  denied  { read } for  pid=98 comm="charger" name="event2" dev="tmpfs" ino=4279 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file
[    4.893576] type=1400 audit(1390866387.605:10): avc:  denied  { open } for  pid=98 comm="charger" name="event2" dev="tmpfs" ino=4279 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file
[    7.288104] type=1400 audit(1390866389.999:12): avc:  denied  { execmem } for  pid=98 comm="charger" scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=process
[    7.288574] type=1400 audit(1390866389.999:13): avc:  denied  { execute } for  pid=98 comm="charger" path="/dev/ashmem" dev="tmpfs" ino=4113 scontext=u:r:healthd:s0 tcontext=u:object_r:ashmem_device:s0 tclass=chr_file

Change-Id: I0118e08514caa0ad11d2aa7562c9846a96779a21

adbd was only in enforcing for user builds. Commit
Ib33c0dd2dd6172035230514ac84fcaed2ecf44d6 allows us to move
it into enforcing for everyone. Do it.

Change-Id: Ie1a3e5361c891d2c9366e11f35699e3146cc3d88

Require all domain transitions or dyntransitions to be
explicitly specified in SELinux policy.

healthd: Remove healthd_exec / init_daemon_domain().
Healthd lives on the rootfs and has no unique file type.
It should be treated consistent with other similar domains.

Change-Id: Ief3c1167379cfb5383073fa33c9a95710a883b29

Change-Id: I7c1d2fc7b4d5a962f872d5f032b6d9e31efe7a24

Change-Id: Id1eb5f7524181aaa17d0ce26219167a5b05cfd4f

When setting a static wallpaper on multiple devices the
following denials were encountered.
   avc:  denied  { getattr } for  pid=1775 comm="llpaper_chooser" path="/data/system/users/0/wallpaper" dev="mmcblk0p23" ino=104679 scontext=u:r:shared_app:s0 tcontext=u:object_r:wallpaper_file:s0 tclass=file
   avc:  denied  { getattr } for  pid=799 comm="ndroid.systemui" path="/data/system/users/0/wallpaper" dev="mmcblk0p23" ino=104679 scontext=u:r:platform_app:s0 tcontext=u:object_r:wallpaper_file:s0 tclass=file
   avc:  denied  { getattr } for  pid=1909 comm=4173796E635461736B202332 path="/data/system/users/0/wallpaper" dev="mmcblk0p28" ino=586422 scontext=u:r:release_app:s0 tcontext=u:object_r:wallpaper_file:s0 tclass=file

platform_app access is from the SystemUI app whereas the other
denials are from the Launcher that is used on the particular
device. For instance, Launcher2 triggers the shared_app denial
whereas release_app (used by Launcher3) triggers the other denial.
Because of this, add the rule to all appdomains.

The static wallpaper is still set without this change. Just add
the rule to avoid the noise in the logs.

Change-Id: Ida84d1695d52379d67b87318403f629fd07109a4
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>

When adbd runs as root, it transitions into the
su domain. Add the various rules to support this.

This is needed to run the adbd and shell domains in
enforcing on userdebug / eng devices without breaking
developer workflows.

Change-Id: Ib33c0dd2dd6172035230514ac84fcaed2ecf44d6

The kernel bug that required healthd to remain permissive was fixed by
I8a3e0db15ec5f4eb05d455a57e8446a8c2b484c2.

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

init creates a private /dev/null instance named /dev/__null__
that is inherited by healthd.  Since it is created prior to
initial policy load, it is left in the tmpfs type.
Allow healthd to inherit and use the open fd.

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

Addresses the following denial.
  avc:  denied  { create } for  pid=605 comm="Binder_2" name="IDM1013" scontext=u:r:mediaserver:s0 tcontext=u:object_r:media_data_file:s0 tclass=dir

Witnessed denial on grouper. Policy change
seems appropriate for core policy though. To
reproduce:
* erase data partition or just delete all dirs
  under /data/mediadrm
* start netflix app and watch a movie

Change-Id: I515a195d45223249847fae70dc2ea9c9b216042f
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>

Triggering a bug report via
Settings > Developer Options > Take bug report
generates a number of denials.

Two bugs here:

1) According to the "allowed" list in
frameworks/native/cmds/servicemanager/service_manager.c ,
media apps, nfc, radio, and apps with system/root UIDs can register
as a binder service. However, they were not placed into the
binder_service domain. Fix them.

2) The bugreport mechanism queries all the services and java
programs and asks them to write to a shell owned file. Grant the
corresponding SELinux capability.

Addresses the following denials:

<5>[  149.342181] type=1400 audit(1389419775.872:17): avc:  denied  { write } for  pid=4023 comm="dumpsys" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:keystore:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  149.371844] type=1400 audit(1389419775.902:18): avc:  denied  { write } for  pid=4023 comm="dumpsys" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:healthd:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  149.980161] type=1400 audit(1389419776.512:22): avc:  denied  { write } for  pid=4023 comm="dumpsys" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:drmserver:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  150.095066] type=1400 audit(1389419776.622:23): avc:  denied  { write } for  pid=1514 comm="Binder_C" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:system_app:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  150.096748] type=1400 audit(1389419776.632:24): avc:  denied  { getattr } for  pid=3178 comm="Binder_3" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:system_app:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  150.097090] type=1400 audit(1389419776.632:25): avc:  denied  { write } for  pid=1514 comm="Binder_C" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  154.545583] type=1400 audit(1389419781.072:43): avc:  denied  { write } for  pid=1423 comm="Binder_A" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:media_app:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  156.000877] type=1400 audit(1389419782.532:44): avc:  denied  { write } for  pid=1423 comm="Binder_A" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:radio:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  156.022567] type=1400 audit(1389419782.552:45): avc:  denied  { write } for  pid=1423 comm="Binder_A" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:radio:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  156.043463] type=1400 audit(1389419782.572:46): avc:  denied  { write } for  pid=1423 comm="Binder_A" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:nfc:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
<5>[  156.062550] type=1400 audit(1389419782.592:47): avc:  denied  { write } for  pid=1423 comm="Binder_A" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-10-21-55-46.txt.tmp" dev="mmcblk0p28" ino=82094 scontext=u:r:radio:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file

Change-Id: I365d530c38ce176617e48b620c05c4aae01324d3

Previous bluetooth denials should be addressed by
I14b0530387edce1097387223f0def9b59e4292e0.

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

Re-purpose the existing bluetooth_socket type, originally
for /dev/socket/bluetooth used by bluetoothd in the old
bluetooth stack, for sockets created by bluedroid under
/data/misc/bluedroid, and allow mediaserver to connect
to such sockets.  This is required for playing audio
on paired BT devices.

Based on b/12417855.

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

These are all symlinks. The restorecon in /sys doesn't follow
symlinks, so these lines have absolutely no effect, and just
serve to confuse people.

Remove them.

Change-Id: I24373fa0308ec700011ed19b1ce29a491d1feff3

powervr_device is obsoleted by the more general gpu_device.
akm_device and accelerometer_device are obsoleted by the more
general sensors_device.

We could also drop the file_contexts entries altogether and
take them to device-specific policy (in this case, they all
came from crespo, so that is obsolete for master).

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

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

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

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

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

The recovery console now has its own domain and therefore we do not
need to allow this for unconfined domains.

This reverts commit 43ddc106.

Change-Id: Id2d2c02ccf6ac38c48b07ab84b73348cd9c815fa