Writing to the /proc/self/attr files (encapsulated by the libselinux
set*con functions) enables a program to request a specific security
context for various operations instead of the policy-defined defaults.
The security context specified using these calls is checked by an
operation-specific permission, e.g. dyntransition for setcon,
transition for setexeccon, create for setfscreatecon or
setsockcreatecon, but the ability to request a context at all
is controlled by a process permission.  Omit these permissions from
domain.te and only add them back where required so that only specific
domains can even request a context other than the default defined by
the policy.

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

We added these rules to the kernel domain when we removed them
from unconfined to ensure that we did not break anything.  But
we have seen no uses of these rules and this matches our expectation
that any actual operations that require these permissions occurs
after switching to the init domain.

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

Kernel userspace helpers may be spawned running in the kernel
SELinux domain. Those userspace helpers shouldn't be able to turn
SELinux off.

This change revisits the discussion in
https://android-review.googlesource.com/#/c/71184/

At the time, we were debating whether or not to have an allow rule,
or a dontaudit rule. Both have the same effect, as at the time we
switch to enforcing mode, the kernel is in permissive and the operation
will be allowed.

Change-Id: If335a5cf619125806c700780fcf91f8602083824

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>

Only allow to domains as required and amend the existing
neverallow on block_device:blk_file to replace the
exemption for unconfineddomain with an explicit whitelist.
The neverallow does not check other device types as specific
ones may need to be writable by device-specific domains.

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

Remove sys_ptrace and add a neverallow for it.
Remove sys_rawio and mknod, explicitly allow to kernel, init, and recovery,
and add a neverallow for them.
Remove sys_module.  It can be added back where appropriate in device
policy if using a modular kernel.  No neverallow since it is device
specific.

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

Only allow to specific domains as required, and add a neverallow
to prevent allowing it to other domains not explicitly whitelisted.
sdcard_type is exempted from the neverallow since more domains
require the ability to mount it, including device-specific domains.

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

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

Now that we set /sys/fs/selinux/checkreqprot via init.rc,
restrict the ability to set it to only the kernel domain.

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

As per the discussion in:
https://android-review.googlesource.com/#/c/71184/



init sets the enforcing mode in its code prior to switching to
the init domain via a setcon command in the init.rc file.  Hence,
the setenforce permission is checked while still running in the
kernel domain.  Further, as init has no reason to ever set the
enforcing mode again, we do not need to allow setenforce to the
init domain and this prevents reverting to permissive
mode via an errant write by init later.  We could technically
dontaudit the kernel setenforce access instead since the first
call to setenforce happens while still permissive (and thus we
never need to allow it in policy) but we allow it to more accurately
represent what is possible.

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

The build is broken. Reverting temporarily to fix breakage.

libsepol.check_assertion_helper: neverallow on line 4758 violated by allow init kernel:security { setenforce };
Error while expanding policy
make: *** [out/target/product/mako/obj/ETC/sepolicy_intermediates/sepolicy] Error 1
make: *** Waiting for unfinished jobs....


This reverts commit bf12e225.

Change-Id: I78a05756d8ce3c7d06e1d9d27e6135f4b352bb85

As per the discussion in:
https://android-review.googlesource.com/#/c/71184/



init sets the enforcing mode in its code prior to switching to
the init domain via a setcon command in the init.rc file.  Hence,
the setenforce permission is checked while still running in the
kernel domain.  Further, as init has no reason to ever set the
enforcing mode again, we do not need to allow setenforce to the
init domain and this prevents reverting to permissive
mode via an errant write by init later.  We could technically
dontaudit the kernel setenforce access instead since the first
call to setenforce happens while still permissive (and thus we
never need to allow it in policy) but we allow it to more accurately
represent what is possible.

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

Start running in enforcing mode for kernel / init.
This should be mostly a no-op, as the kernel / init
is in the unconfined domain.

Change-Id: I8273d936c9a4eecb50b78ae93490a4dd52f59eb6

For additional context-

The denials related to init_tmpfs are of the form:

denied  { read } for  pid=12315 comm=""dboxed_process0"" path=2F6465762F6173686D656D2F64616C76696B2D68656170202864656C6574656429 dev=""tmpfs"" ino=9464 scontext=u:r:isolated_app:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file

(the path above is "/dev/ashmem/dalvik-heap (deleted)")

The denials related to executing things from the dalvik cache are of the form:

enied  { execute } for  pid=3565 comm=""dboxed_process0"" path=""/data/dalvik-cache/system@app@Chrome.apk@classes.dex"" dev=""mmcblk0p28"" ino=105983 scontext=u:r:isolated_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file

The denials related to isolated_app and the init socket are:

denied  { getattr } for  pid=3824 comm=""Binder_2"" path=""socket:[14059]"" dev=""sockfs"" ino=14059 scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket

The getopt denials for the aforementioned socket are:

denied  { getopt } for  pid=3824 comm=""Binder_2"" path=""/dev/socket/dumpstate"" scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket

Change-Id: I3c57702e2af5a779a7618da9aa40930e7f12ee49

For unlabeled files, revert to DAC rules. This is for backwards
compatibility, as files created before SELinux was in place may
not be properly labeled.

Over time, the number of unlabeled files will decrease, and we can
(hopefully) remove this rule in the future.

To prevent inadvertantly introducing the "relabelto" permission, add
a neverallow domain, and add apps which have a legitimate need to
relabel to this domain.

Bug: 9777552
Change-Id: I71b0ff8abd4925432062007c45b5be85f6f70a88

Bug: 4070557
Change-Id: I027f76cff6df90e9909711cb81fbd17db95233c1