AVC message we get without this change creating
/data/misc/vold/user_keys

05-12 08:57:54.839   189   189 W vold    : type=1400 audit(0.0:176):
avc: denied { create } for name="user_keys" scontext=u:r:vold:s0
tcontext=u:object_r:vold_data_file:s0 tclass=dir permissive=0

Bug: 19704432
Change-Id: I10fc90c64c7c10fa9811133a4289663ae8617607

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>

This is one of three changes to enable this functionality:
  https://android-review.googlesource.com/#/c/146259/
  https://android-review.googlesource.com/#/c/146264/
  https://android-review.googlesource.com/#/c/146265/

Bug: 18151196

Change-Id: I6ce4bc977a548df93ea5c09430f93eef5ee1f9fa

Move all key management into vold
Reuse vold's existing key management through the crypto footer
to manage the device wide keys.

Use ro.crypto.type flag to determine crypto type, which prevents
any issues when running in block encrypted mode, as well as speeding
up boot in block or no encryption.

This is one of four changes to enable this functionality:
  https://android-review.googlesource.com/#/c/148586/
  https://android-review.googlesource.com/#/c/148604/
  https://android-review.googlesource.com/#/c/148606/
  https://android-review.googlesource.com/#/c/148607/

Bug: 18151196

Change-Id: I3208b76147df9da83d34cf9034675b0689b6c3a5

This reverts commit 5287d9a8.

Change-Id: I9ec0db0718da7088dc2b66f5b1749b8fb069575a

This change removes the link, but moves key management to
vold, so we need to adjust permissions alternately.

This is one of four changes to enable this functionality:
  https://android-review.googlesource.com/#/c/144586/
  https://android-review.googlesource.com/#/c/144663/
  https://android-review.googlesource.com/#/c/144672/
  https://android-review.googlesource.com/#/c/144673/

Bug: 18151196
Change-Id: I58d3200ae0837ccdf1b8d0d6717566a677974cf1

This enables an optimization of bypassing the FUSE overhead when
migrating emulated storage between volumes.

avc: denied { write } for path="/mnt/expand/6cba9b95-4fc8-4096-b51f-bdb2c007d059/media/obb/.nomedia" dev="dm-0" ino=387843 scontext=u:r:vold:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=file permissive=1

Bug: 19993667
Change-Id: I2bb9aaca50ed988ded6afec6d7fbe190903707e0

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

vold works with two broad classes of block devices: untrusted devices
that come in from the wild, and trusted devices.

When running blkid and fsck, we pick which SELinux execution domain
to use based on which class the device belongs to.

Bug: 19993667
Change-Id: I44f5bac5dd94f0f76f3e4ef50ddbde5a32bd17a5

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

Create new vold_fsck domain that only has access to vold_block
devices to prevent any access to internal userdata.

Change-Id: I25ddcd16cbf83d7a25b70bc64d95f5345d0d5731

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

Assign a more specific type than block_device to all
block devices created or accessed by vold.   Allow vold
to set the context on the device nodes it creates.

vold can create extra loop devices (/dev/block/loopN) and
block devices for volumes it manages (/dev/block/vold/M:N).

vold can read/write device mapper block devices (/dev/block/dm-N)
created for encrypted volumes.

vold can read/write metadata partitions used to store encryption metadata.
The metadata_block_device type should be assigned in device-specific
policy to the partition specified by the encryptable= mount option
for the userata entry in the fstab.<board> file.

This change does not remove the ability to create or read/write
generic block_device devices by vold, so it should not break anything.
It does add an auditallow statement on such accesses so that we can track
remaining cases where we need to label such device nodes so that we can
ultimately remove this access.

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

Allow error reporting via the pty supplied by init.
Allow vold to invoke fsck for checking volumes.

Addresses denials such as:
avc:  denied  { ioctl } for  pid=133 comm="e2fsck" path="/dev/pts/0" dev="devpts" ino=3 scontext=u:r:fsck:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file

avc: denied { execute } for pid=201 comm="vold" name="e2fsck" dev="mmcblk0p25" ino=98 scontext=u:r:vold:s0 tcontext=u:object_r:fsck_exec:s0 tclass=file

These denials show up if you have encrypted userdata.

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

Introduce separate types for the userdata and cache block
devices so that we can assign them and allow access to them
in device-specific policy without allowing access to any other
block device (e.g. system).  These types will only be used if
assigned to device node paths in the device-specific file_contexts
configuration.  Otherwise, this change will have no impact - the
userdata and cache block devices will continue to default to block_device
type.

To avoid breakage when these new types are assigned to the userdata
block device, allow access by vold and uncrypt, but auditallow
these accesses to confirm that these are required.

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

The bugs that motivated bringing back the unlabeled allowall rules,
https://android-review.googlesource.com/#/c/94971/
should be resolved by the following changes:
https://android-review.googlesource.com/#/c/94966/
https://android-review.googlesource.com/#/c/96080/



Beyond those changes, installd needs to be able to remove package directories
for apps that no longer exist or have moved (e.g. to priv-app) on upgrades, so
allow it the permissions required for this purpose.  vold needs to be able
to chown/chmod/restorecon files in asec containers so allow it the
permissions to do so.  system_server tries to access all /data/data
subdirectories so permit it to do so.  installd and system_server
read the pkg.apk file before it has been relabeled by vold and therefore
need to read unlabeled files.

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

Introduce wakelock_use(). This macro declares that a domain uses
wakelocks.

Wakelocks require both read-write access to files in /sys/power, and
CAP_BLOCK_SUSPEND. This macro helps ensure that both capabilities and
file access are granted at the same time.

Still TODO: fix device specific wakelock use.

Change-Id: Ib98ff374a73f89e403acd9f5e024988f59f08115

This was originally to limit the ability to relabel files to
particular types given the ability of all domains to relabelfrom
unlabeled files.  Since the latter was removed by
Ied84f8b4b1a0896c1b9f7d783b7463ce09d4807b, this no longer serves
any purpose.

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

Bug: 9467042

(cherry picked from commit d7567118)

Change-Id: Ic6ef6031149287c863714ca370a42fd8b1efe93c

Bug: 9467042
Change-Id: Ice72e6c3047d1439e6fa6997b5f47f807f34b28d

The ctl_default_prop label is a bit too generic for some
of the priveleged domains when describing access rights.
Instead, be explicit about which services are being started
and stopped by introducing new ctl property keys.

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

vold needs to be able to check remaining battery to safely abort
certain operations

Bug: 11985952
Change-Id: I7dfe83f7d1029593882e0e5ad33f90fb29e5532b

This new type will allow us to write finer-grained
policy concerning asec containers. Some files of
these containers need to be world readable.

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

(cherry picked from commit 48b18832)

Change-Id: Ic75095397a11ad715c16a75a7374e9b0d131f3f7

Replace * or any permission set containing create with
create_socket_perms or create_stream_socket_perms.

Add net_domain() to all domains using network sockets and
delete rules already covered by domain.te or net.te.

For netlink_route_socket, only nlmsg_write needs to be separately
granted to specific domains that are permitted to modify the routing
table.   Clarification:  read/write permissions are just ability to
perform read/recv() or write/send() on the socket, whereas nlmsg_read/
nlmsg_write permissions control ability to observe or modify the
underlying kernel state accessed via the socket.
See security/selinux/nlmsgtab.c in the kernel for the mapping of
netlink message types to nlmsg_read or nlmsg_write.

Delete legacy rule for b/12061011.

This change does not touch any rules where only read/write were allowed
to a socket created by another domain (inherited across exec or
received across socket or binder IPC).  We may wish to rewrite some or all
of those rules with the rw_socket_perms macro but that is a separate
change.

Change-Id: Ib0637ab86f6d388043eff928e5d96beb02e5450e
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>

When encrypting a device, vold tries to acquire a wake lock,
to prevent the device from sleeping. Add an allow rule.

After booting with a freshly encrypted device, fsck logs data to
/dev/fscklogs/log . Add an allow rule.

Addresses the following denials.

wake lock:

<5>[  372.401015] type=1400 audit(1387488823.195:6): avc:  denied  { read write } for  pid=143 comm="vold" name="wake_lock" dev="sysfs" ino=69 scontext=u:r:vold:s0 tcontext=u:object_r:sysfs_wake_lock:s0 tclass=file
<5>[  127.274556] type=1400 audit(1387494536.080:8): avc:  denied  { open } for  pid=140 comm="vold" name="wake_lock" dev="sysfs" ino=69 scontext=u:r:vold:s0 tcontext=u:object_r:sysfs_wake_lock:s0 tclass=file

fsck logging:

<5>[   44.759122] type=1400 audit(1387489522.460:6): avc:  denied  { search } for  pid=132 comm="vold" name="fscklogs" dev="tmpfs" ino=3216 scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=dir
<5>[   28.559964] type=1400 audit(1387495221.265:6): avc:  denied  { write } for  pid=132 comm="vold" name="fscklogs" dev="tmpfs" ino=3216 scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=dir
<5>[   28.560081] type=1400 audit(1387495221.265:7): avc:  denied  { add_name } for  pid=132 comm="vold" name="log" scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=dir
<5>[   28.560244] type=1400 audit(1387495221.265:8): avc:  denied  { create } for  pid=132 comm="vold" name="log" scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=file
<5>[   28.560383] type=1400 audit(1387495221.265:9): avc:  denied  { write open } for  pid=132 comm="vold" name="log" dev="tmpfs" ino=5898 scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=file
<5>[   28.582520] type=1400 audit(1387495221.285:10): avc:  denied  { getattr } for  pid=132 comm="vold" path="/dev/fscklogs/log" dev="tmpfs" ino=5898 scontext=u:r:vold:s0 tcontext=u:object_r:fscklogs:s0 tclass=file

Change-Id: I09fbe73c9d4955578c16fece4f3b84269eed78b5

Fixes this specific violation:

type=1400 audit(1384468728.202:16): avc:  denied { read write } for
pid=271 comm="vold" name="test1.obb" dev="fuse" ino=3100664872
scontext=u:r:vold:s0 tcontext=u:object_r:sdcard_internal:s0
tclass=file

Bug: 11693888
Change-Id: I45d30ecabdf0bc8871f3dd67b5695ac909109d9a

Bug: 11175082
Change-Id: Ic1bd15e8729583be199551ec6baeb4acaf46c210

It's questionable whether this change is actually needed,
and it only affects one user (who's /data partition was
created oddly).

Revert it for now (in master) to see if we get more reports
of this bug.

Bug: 11149726
Change-Id: I9b5408306b55653b2b9d43e68e7c771b72662649

Fixes:
denied  { relabelto } for  pid=721 comm="PackageManager" name="vmdl-112554949.tmp" dev="mmcblk0p30" ino=712747 scontext=u:r:system:s0 tcontext=u:object_r:apk_private_tmp_file:s0 tclass=file
denied  { create } for  pid=240 comm="vold" name="smdl2tmp1.asec" scontext=u:r:vold:s0 tcontext=u:object_r:system_data_file:s0 tclass=file

Bug: 11149726
Change-Id: Iddc7592c757375a961f0d392c27622073c141b36

Bug: 10706792
Change-Id: I85085ab7a6f0f3d12ba4d2b21b655bb64795495f

This is needed for the new fuse wrapped sdcard support.

bug: 10330128

Change-Id: Ic5ebc769d376bf061d237616e56bcd562a63c6be

This fixes the issue where paid apps failed to install via Google
Play with "Package file has a bad manifest" error. The issue appears
to be caused by vold being prevented by SELinux policy from setting
the setgid bit on the ASEC container directory into which the APK is
decrypted. As a result, the APK is not readable to PackageParser.

Bug: 9736808
Change-Id: I07546a9f9caac3de8b720499bd1bf1604edea0fe

This fixes the issue where paid apps failed to install via Google
Play with "Package file has a bad manifest" error. The issue appears
to be caused by vold being prevented by SELinux policy from setting
the setgid bit on the ASEC container directory into which the APK is
decrypted. As a result, the APK is not readable to PackageParser.

Bug: 9736808
Change-Id: I07546a9f9caac3de8b720499bd1bf1604edea0fe

This change enables SELinux security enforcement on vold.

For the vold.te file ONLY, this change is conceptually a revert of
77d4731e and
50e37b93, with the following
additional changes:

1) Removal of "allow vold proc:file write;" and
"allow vold self:capability { sys_boot };". As of system/vold
change adfba3626e76c1931649634275d241b226cd1b9a, vold no longer
performs it's own reboots, so these capabilities are no longer
needed.

2) Addition of the powerctl property, which vold contacts to
tell init to reboot.

3) Removal of "allow vold kernel:system module_request;". As of
CTS commit f2cfdf5c057140d9442fcfeb4e4a648e8258b659, Android
devices no longer ship with loadable modules, hence we don't
require this rule.

4) Removal of "fsetid" from "self:capability". Any setuid / setgid
bits SHOULD be cleared if vold is able to change the permissions
of files. IMHO, it was a mistake to ever include this capability in
the first place.

Testing: As much as possible, I've tested filesystem related
functionality, including factory reset and device encryption.
I wasn't able to test fstrim functionality, which is a fairly
new feature.  I didn't see any policy denials in dmesg. It's quite
possible I've missed something. If we experience problems, I
happy to roll back this change.

Bug: 9629920
Change-Id: I683afa0dffe9f28952287bfdb7ee4e0423c2e97a

This prevents denials from being generated by the base policy.
Over time, these rules will be incrementally tightened to improve
security.

Change-Id: I4be1c987a5d69ac784a56d42fc2c9063c402de11

Bug: 4070557
Change-Id: I027f76cff6df90e9909711cb81fbd17db95233c1

Change-Id: I40f3ccd9813e0a337ced0a44e686ab489277d78b

I have no idea what vold is doing when this operation is attempted
(when a full-disk encrypted device is booting up). Thus, I don't know
if there is a better way of restricting the policy.

Change-Id: I537b70b1abb73c36e5abf0357b766292f625e1af