Revert the neverallow change portion of
356df327, in case others need to
do dynamic policy updates.

(cherrypicked from commit e827a8ab)

Bug: 22885422
Bug: 8949824
Change-Id: If0745e7f83523377fd19082cfc6b33ef47ca0647

Remove the ability to dynamically update SELinux policy on the
device.

1) This functionality has never been used, so we have no idea if
it works or not.

2) If system_server is compromised, this functionality allows a
complete bypass of the SELinux policy on the device. In particular,
an attacker can force a regression of the following patch
  * https://android-review.googlesource.com/138510
see also https://code.google.com/p/android/issues/detail?id=181826

3) Dynamic policy update can be used to bypass neverallow protections
enforced in CTS, by pushing a policy to the device after certification.
Such an updated policy could bring the device out of compliance or
deliberately introduce security weaknesses.

(cherrypicked from commit e827a8ab)

Bug: 22885422
Bug: 8949824
Change-Id: I802cb61fd18a452a2bb71c02fe57cfce5b7e9dc8

Add a neverallow rule (compile time assertion) for /data/local/tmp
access. /data/local/tmp is intended entirely for the shell user, and
it's dangerous for other SELinux domains to access it. See, for example,
this commit from 2012:

  https://android.googlesource.com/platform/system/core/+/f3ef1271f225d9f00bb4ebb0573eb3e03829f9a8

Change-Id: I5a7928ae2b51a574fad4e572b09e60e05b121cfe

Revert the neverallow change portion of
356df327, in case others need to
do dynamic policy updates.

Bug: 22885422
Bug: 8949824
Change-Id: If2c13d112b346db5c011a6a61bc4486b43d46d61

Remove the ability to dynamically update SELinux policy on the
device.

1) This functionality has never been used, so we have no idea if
it works or not.

2) If system_server is compromised, this functionality allows a
complete bypass of the SELinux policy on the device. In particular,
an attacker can force a regression of the following patch
  * https://android-review.googlesource.com/138510
see also https://code.google.com/p/android/issues/detail?id=181826

3) Dynamic policy update can be used to bypass neverallow protections
enforced in CTS, by pushing a policy to the device after certification.
Such an updated policy could bring the device out of compliance or
deliberately introduce security weaknesses.

Bug: 22885422
Bug: 8949824
Change-Id: Id98b5e09d79254816d920b92003efe8dcbe6cd2e

Change-Id: I08aaf89e2ef23f9528d107a1c9d66c1c9979b3ac

Init never uses / add service manager services. It doesn't make
sense to allow these rules to init. Adding a rule of this type
is typically caused by a process inappropriately running in init's
SELinux domain, and the warning message:

  Warning!  Service %s needs a SELinux domain defined; please fix!

is ignored.

In addition, add neverallow rules to domain.te which prevent
nonsense SELinux service_manager rules from being added.

Change-Id: Id04a50d1826fe451a9ed216aa7ab249d0393cc57

(cherry pick from commit 0d22c6ce)

- 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

- 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

(cherry-picked from change f7163597)

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

(chery-picked from commit 13dec5fa)

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 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

Don't allow init to mount on top of /proc. See
https://android-review.googlesource.com/148295 for details.

Change-Id: I65f66b39f3a5bfb72facb9f716f4537ac2237af1

This reverts commit c450759e.

There was nothing wrong with this change originally --- the companion
change in init was broken.

Bug: http://b/19702273
Change-Id: I9d806f6ac251734a61aa90c0741bec7118ea0387

shamu isn't booting.

This reverts commit 46e832f5.

Change-Id: Ib697745a9a1618061bc72f8fddd7ee88c1ac5eca

Change-Id: I5eca4f1f0f691be7c25e463563e0a4d2ac737448

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

Add selinux rules to allow file level encryption to work

Change-Id: I1e4bba23e99cf5b2624a7df843688fba6f3c3209

Add selinux rules to allow file level encryption to work

Change-Id: I1e4bba23e99cf5b2624a7df843688fba6f3c3209

Allow init to

 1. Access device mapper to set up dm-verity devices

    avc:  denied  { write } for  pid=156 comm="init" name="device-mapper" dev="tmpfs" ino=6229 scontext=u:r:init:s0 tcontext=u:object_r:dm_device:s0 tclass=chr_file permissive=0

 2. Access the metadata partition to load and store dm-verity state

    avc:  denied  { write } for  pid=1 comm="init" name="mmcblk0p25" dev="tmpfs" ino=6408 scontext=u:r:init:s0 tcontext=u:object_r:metadata_block_device:s0 tclass=blk_file permissive=0

 3. Read /sys/fs/pstore/console-ramoops to detect restarts triggered
    by dm-verity

    avc:  denied  { getattr } for  pid=1 comm="init" path="/sys/fs/pstore/console-ramoops" dev="pstore" ino=9911 scontext=u:r:init:s0 tcontext=u:object_r:pstorefs:s0 tclass=file permissive=0

These can be reproduced using the following steps:

 1. Add fs_mgr flag verify to the system partition in fstab

 2. Add a device specific init.rc handler for the init action that
    calls the built-in command verity_load_state.

Change-Id: Id8790ae4b204ca66e671eefd3820d649f1d1e7ba

As of https://android-review.googlesource.com/127858 ,
open(O_RDONLY) is no longer used for chmod. It's no
longer necessary to allow init to read the SELinux policy.

Change-Id: I691dd220827a01a8d7a9955b62f8aca50eb25447

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

When encrypting a device, or when an encrypted device boots,
a tmpfs is mounted in place of /data, so that a pseudo filesystem
exists to start system_server and related components. SELinux labels
need to be applied to that tmpfs /data so the system boots
properly.

Allow init to relabel a tmpfs /data.

Addresses the following denial:

[    6.294896] type=1400 audit(29413651.850:4): avc:  denied  { relabelfrom } for  pid=1 comm="init" name="/" dev="tmpfs" ino=6360 scontext=u:r:init:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir

Steps to reproduce:
  1) Go into Settings > Security > Encrypt Phone
  2) Encrypt phone
  3) See denial
  4) reboot phone
  5) See denial on boot

Bug: 19050686
Change-Id: Ie57864fe1079d9164d5cfea44683a97498598e41

Add rules to allow /sbin/slideshow to access framebuffer and input
devices at early stages of boot, and rules to allow init to execute
the program (from init.rc using exec).

Needed by changes from
  I58c79a7f3ac747eec0d73a10f018d3d8ade9df7d

Change-Id: I1d5018feb7025853f0bf81651f497fef8c3a6ab0

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>

We allow chmod/chown of files / directories by init, but don't allow
init to search into subdirectories. Feels wrong.

Addresses the following denial:

  avc:  denied  { search } for  pid=1 comm="init" name="/" dev="pstore" ino=5570 scontext=u:r:init:s0 tcontext=u:object_r:pstorefs:s0 tclass=dir permissive=1

which results from the following init.rc statement:

  # pstore/ramoops previous console log
  mount pstore pstore /sys/fs/pstore
  chown system log /sys/fs/pstore/console-ramoops
  chmod 0440 /sys/fs/pstore/console-ramoops
  chown system log /sys/fs/pstore/pmsg-ramoops-0
  chmod 0440 /sys/fs/pstore/pmsg-ramoops-0

Bug: 19050686
Change-Id: I0528ecb17686891b66262de1f3c229cc68a56830

Change-Id: I40a3d089a4a2325abcd1e12aa57b1fd97a1f7902

SELinux domains wanting read access to /proc/net need to
explicitly declare it.

TODO: fixup the ListeningPortsTest cts test so that it's not
broken.

Bug: 9496886
Change-Id: Ia9f1214348ac4051542daa661d35950eb271b2e4

Commit 0d08d472 added two auditallow
statements. The intented purpose of the auditallow statement was:

  auditallow accesses by init to files
  and character devices left in the generic device type so we can monitor
  what is being left there, although it is not necessarily a problem unless
  the file or device should be accessible to others.

As currently written, the auditallow rules aren't actionable. It's not
a problem by itself for init to access a /dev file or chr_file.
Rather, we care about when other domains access such files.

Currently, this generates a number of (expected) audit statements on
boot, which causes unnecessary confusion and makes people believe
that something is broken.

Remove the unactionable auditallow statements.

Change-Id: Ibfe33976505a7dc3f8d15c9eb203c044a39da426

On the Nexus 9, init.rc creates the /vendor -> /system/vendor
symlink, then a bit later removes the symlink, creates a
proper directory, and mounts /vendor on the directory.

The current permissive SELinux policy doesn't allow init to
remove the /vendor symlink, which eventually causes the following
errors:

  avc:  denied  { unlink } for  pid=136 comm="init" name="vendor" dev="rootfs" ino=6454 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=lnk_file permissive=1
  fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/platform/sdhci-tegra.3/by-name/VNR at /vendor options: (null) error: Too many symbolic links encountered

There was an attempt to reorder some of these operations so
we didn't have to create / delete the symlink, but it
doesn't seem to have gone well.
https://android.googlesource.com/platform/system/core/+/f67d6bd3c0fb41d167c675b9d2b5d377b6f38a74

Change-Id: I4d01661d4228e44e18465fe16ce4a70fe2a83042

init.rc files can potentially chown/chmod any character device, so
allow it for everything except for kmem (prohibited by neverallow).
While we could whitelist each of the device types, doing so would also
require device-specific changes for the device-specific types and
may be difficult to maintain.

Resolves (permissive) denials such as:
avc:  denied  { read } for  pid=1 comm="init" name="ttySAC0" dev="tmpfs" ino=4208 scontext=u:r:init:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1

avc:  denied  { open } for  pid=1 comm="init" name="ttySAC0" dev="tmpfs" ino=4208 scontext=u:r:init:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1

avc:  denied  { setattr } for  pid=1 comm="init" name="ttySAC0" dev="tmpfs" ino=4208 scontext=u:r:init:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1

avc:  denied  { read } for  pid=1 comm="init" name="smd7" dev="tmpfs" ino=6181 scontext=u:r:init:s0 tcontext=u:object_r:radio_device:s0 tclass=chr_file

avc:  denied  { open } for  pid=1 comm="init" name="smd7" dev="tmpfs" ino=6181 scontext=u:r:init:s0 tcontext=u:object_r:radio_device:s0 tclass=chr_file

avc:  denied  { read } for  pid=1 comm="init" name="wcnss_wlan" dev="tmpfs" ino=7475 scontext=u:r:init:s0 tcontext=u:object_r:wlan_device:s0 tclass=chr_file

avc:  denied  { open } for  pid=1 comm="init" name="wcnss_wlan" dev="tmpfs" ino=7475 scontext=u:r:init:s0 tcontext=u:object_r:wlan_device:s0 tclass=chr_file

avc:  denied  { setattr } for  pid=1 comm="init" name="wcnss_wlan" dev="tmpfs" ino=7475 scontext=u:r:init:s0 tcontext=u:object_r:wlan_device:s0 tclass=chr_file

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

Resolves (permissive) denials on upgrades from 4.4.

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

Switch the kernel and init domains from unconfined_domain()
to permissive_or_unconfined() so that we can start collecting
and addressing denials in -userdebug/-eng builds.

Also begin to address denials for kernel and init seen after
making this switch.

I intentionally did not allow the following denials on hammerhead:
avc:  denied  { create } for  pid=1 comm="init" name="memory.move_charge_at_immigrate" scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
avc:  denied  { open } for  pid=1 comm="init" name="memory.move_charge_at_immigrate" dev="tmpfs" ino=6550 scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file

These occur when init.rc does:
write /sys/fs/cgroup/memory/memory.move_charge_at_immigrate 1
because the prior command to mount the cgroup failed:
mount cgroup none /sys/fs/cgroup/memory memory

I think this is because that cgroup is not enabled in the
kernel configuration.  If the cgroup mount succeeded,
then this would have been a write to a cgroup:file and
would have been allowed already.

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

With the sepolicy-analyze neverallow checking, attribute
expansion is performed against the device policy and therefore
we do not want our neverallow rules to exempt domains from
consideration based on an attribute (e.g. -unconfineddomain).
Otherwise, device policy could pass the neverallow check just
by adding more domains to unconfineddomain.  We could of course
add a CTS test to check the list of unconfineddomains against
a whitelist, but it seems desirable regardless to narrow these
neverallow rules to only the specific domains required.

There are three such neverallow rules in current policy: one
on creating unlabeled files, one on accessing /dev/hw_random, and
one on accessing a character device without a specific type.  The
only domain in unconfineddomain that appears to have a legitimate
need for any of these permissions is the init domain.  Replace
-unconfineddomain with -init in these neverallow rules, exclude these
permissions from unconfineddomain, and add these permissions to init if
not already explicitly allowed.  auditallow accesses by init to files
and character devices left in the generic device type so we can monitor
what is being left there, although it is not necessarily a problem unless
the file or device should be accessible to others.

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

swapon(2) requires write access to the underlying block device.
Allow it.

Addresses the following denial:

   avc:  denied  { write } for  pid=1 comm="init" name="zram0" dev="tmpfs" ino=6267 scontext=u:r:init:s0 tcontext=u:object_r:swap_block_device:s0 tclass=blk_file permissive=0

Change-Id: Id1a4f51038d0b6ce7351294698a0ff146d6e4643

Remove the ability of init to execute programs from / or /system
without changing domains.  This forces all helper programs and
services invoked by init to be assigned their own domain.

Introduce separate domains for running the helper programs
executed from the fs_mgr library by init.  This requires a domain
for e2fsck (named fsck for generality) and a domain for running
mkswap (named toolbox since mkswap is just a symlink to the toolbox
binary and the domain transition occurs on executing the binary, not
based on the symlink in any way).

e2fsck is invoked on any partitions marked with the check mount
option in the fstab file, typically userdata and cache but never
system.  We allow it to read/write the userdata_block_device and
cache_block_device types but also allow it to read/write the default
block_device type until we can get the more specific types assigned
in all of the device-specific policies.

mkswap is invoked on any swap partition defined in the fstab file.
We introduce a new swap_block_device type for this purpose, to be
assigned to any such block devices in the device-specific policies,
and only allow it to read/write such block devices.  As there seem to be
no devices in AOSP with swap partitions in their fstab files, this does
not appear to risk any breakage for existing devices.

With the introduction of these domains, we can de-privilege init to
only having read access to block devices for mounting filesystems; it
no longer needs direct write access to such devices AFAICT.

To avoid breaking execution of toolbox by system services, apps, or the shell,
we allow all domains other than kernel and init the ability to
run toolbox in their own domain.  This is broader than strictly required;
we could alternatively only add it to those domains that already had
x_file_perms to system_file but this would require a coordinated change
with device-specific policy.

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