Add keystore_key class and an action for each action supported
by keystore. Add policies that replicate the access control that
already exists in keystore. Add auditallow rules for actions
not known to be used frequently. Add macro for those domains
wishing to access keystore.
Change-Id: Iddd8672b9e9b72b45ee208e6eda608cc9dc61edc
system_server scans through /proc to keep track of process
memory and CPU usage. It needs to do this for all processes,
not just appdomain processes, to properly account for CPU and
memory usage.
Allow it.
Addresses the following errors which have been showing up
in logcat:
W/ProcessCpuTracker(12159): Skipping unknown process pid 1
W/ProcessCpuTracker(12159): Skipping unknown process pid 2
W/ProcessCpuTracker(12159): Skipping unknown process pid 3
Bug: 15862412
Change-Id: I0a75314824404e060c6914c06a371f2ff2e80512
Property being set: sys.boot_from_charger_mode. If healthd attempts to write
this property without the policy changes we get the following audit message:
[ 45.751195] type=1400 audit(1403556447.444:7): avc: denied { write } for pid=99 comm="charger" name="property_service" dev="tmpfs" ino=3229 scontext=u:r:healthd:s0 tcontext=u:object_r:property_socket:s0 tclass=sock_file permissive=0
These changes are needed to support the following system/core commit:
faster booting from charger mode
* Ieec4494d929e92806e039f834d78b9002afd15c4
Change-Id: I9f198cd73c7b2f1e372c3793dc2b8d5ef26b3a0f
Introduce a net_radio_prop type for net. properties that can be
set by radio or system.
Introduce a system_radio_prop type for sys. properties that can be
set by radio or system.
Introduce a dhcp_prop type for properties that can be set by dhcp or system.
Drop the rild_prop vs radio_prop distinction; this was an early
experiment to see if we could separate properties settable by rild
versus other radio UID processes but it did not pan out.
Remove the ability to set properties from unconfineddomain.
Allow init to set any property. Allow recovery to set ctl_default_prop
to restart adbd.
Change-Id: I5ccafcb31ec4004dfefcec8718907f6b6f3e0dfd
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Don't allow unconfined domains to access the internet. Restrict
internet functionality to domains which explicitly declare their
use. Removing internet access from unconfined domains helps
protect daemons from network level attacks.
In unconfined.te, expand out socket_class_set, and explicitly remove
tcp_socket, udp_socket, rawip_socket, packet_socket, and
appletalk_socket. Remove name_bind, node_bind and name_connect rules,
since they only apply to internet accessible rules.
Add limited udp support to init.te. This is needed to bring up
the loopback interface at boot.
Change-Id: If756f3fed857f11e63a6c3a1a13263c57fdf930a
execmod is checked on attempts to make executable a file mapping
that has been modified. Typically this indicates a text relocation
attempt. As we do not ever allow this for any confined domain to
system_file or exec_type, we should not need it for unconfineddomain
either.
Change-Id: I8fdc858f836ae0d2aa56da2abd7797fba9c258b1
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This is required for the restorecon /adb_keys in init.rc or
for any other relabeling of rootfs files to more specific types on
kernels that support setting security contexts on rootfs inodes.
Addresses denials such as:
avc: denied { relabelfrom } for comm="init" name="adb_keys" dev="rootfs" ino=1917 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file permissive=0
We do not need to prohibit relabelfrom of such files because our goal
is to prevent writing to executable files, while relabeling the file
to another type will take it to a non-executable (or non-writable) type.
In contrast, relabelto must be prohibited by neverallow so that a
modified file in a writable type cannot be made executable.
Change-Id: I7595f615beaaa6fa524f3c32041918e197bfbebe
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Trying to run dumpsys from the serial console generates the
following errors:
shell@device:/ # dumpsys power
[ 3244.099015] binder: 2259:2259 transaction failed 29201, size 28-8
[ 3244.099291] type=1400 audit(1403313679.642:12): avc: denied { read write } for pid=2259 comm="dumpsys" path="/dev/console" dev="tmpfs" ino=6188 scontext=u:r:system_server:s0 tcontext=u:object_r:console_device:s0 tclass=chr_file permissive=0
Error dumping service info: (Unknown error -2147483646) power
and the operation fails. Allow binderservicedomains to perform
writes to /dev/console.
Bug: 15779131
Change-Id: Iff55ab09c3a4d40e12d49ff2308bf147f9cb6937
The init.rc one-shot services "defaultcrypto" and "encrypt" call
out to the /system/bin/vdc command line to ask vold to perform
encryption operations. Create a new domain for these one-shot
services. Allow the vdc domain to talk to vold.
Change-Id: I73dc2ee4cc265bc16056b27307c254254940fd9f
sdcard_internal is assigned to fuse mounts while sdcard_external
is assigned to vfat mounts by genfs_contexts. Originally we
allowed access to both via the sdcard_type attribute, and access
via both means was required. IIUC however, in 4.4 and later,
SDcard access should always occur via the fuse mount and we can
drop access to sdcard_external.
I think we can do the same for all domains except sdcardd. However,
I cannot test this as the Nexus devices do not have external SDcard
support.
Also wondering if we should rename sdcard_internal type to fuse
and sdcard_external type to vfat to more clearly represent their
meaning, since one accesses the external SDcard via the fuse mount now.
Change-Id: Ie44221e9eea90e627a48df5398c456b86293f724
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Require sdcard_type access to be explicitly allowed to
each domain. This is to both protect services from
being killed by unsafe ejection and to protect SDcard
data from access by rogue daemons.
Change-Id: If3bdd50fd2be50bd98d755b2f252e0ae455b82c4
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Require app_data_file access to be explicitly allowed to
each domain. We especially do not want to allow
app_data_file:lnk_file read to any privileged domain.
But removing app_data_file access in general can be useful
in protecting app data from rogue daemons.
Change-Id: I46240562bce76579e108495ab15833e143841ad8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove write access to rootfs files from unconfineddomain and
prevent adding it back via neverallow. This is only applied to
regular files, as we are primarily concerned with preventing
writing to a file that can be exec'd and because creation of
directories or symlinks in the rootfs may be required for mount
point directories.
Change-Id: If2c96da03f5dd6f56de97131f6ba9eceea328721
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
execute_no_trans controls whether a domain can execve a program
without switching to another domain. Exclude this permission from
unconfineddomain, add it back to init, init_shell, and recovery for
files in / and /system, and to kernel for files in / (to permit
execution of init prior to setcon). Prohibit it otherwise for the
kernel domain via neverallow. This ensures that if a kernel task
attempts to execute a kernel usermodehelper for which no domain transition
is defined, the exec will fail.
Change-Id: Ie7b2349923672dd4f5faf7c068a6e5994fd0e4e3
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
system_server needs to open /dev/snd and access files
within that directory. Allow it.
system_server need to parse the ALSA card descriptors after a USB device
has been inserted. This happens from USBService in system_server.
Addresses the following denial:
system_server( 1118): type=1400 audit(0.0:19): avc: denied { search } for comm=5573625365727669636520686F7374 name="snd" dev="tmpfs" ino=8574 scontext=u:r:system_server:s0 tcontext=u:object_r:audio_device:s0 tclass=dir
and likely others
Change-Id: Id274d3feb7bf337f492932e5e664d65d0b8d05b8
Add neverallow rules to prohibit adding any transitions into
the kernel or init domains. Rewrite the domain self:process
rule to use a positive permission list and omit the transition
and dyntransition permissions from this list as well as other
permissions only checked when changing contexts. This should be
a no-op since these permissions are only checked when
changing contexts but avoids needing to exclude kernel or init
from the neverallow rules.
Change-Id: Id114b1085cec4b51684c7bd86bd2eaad8df3d6f8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Also rewrite to use positive permission sets, macros, and
eliminate duplication.
Change-Id: I4dc340784f770e569160025a5db2dc3da90d2629
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As reported by sepolicy-analyze -D -P /path/to/sepolicy.
No semantic difference reported by sediff between the policy
before and after this change.
Deduplication of selinuxfs read access resolved by taking the
common rules to domain.te (and thereby getting rid of the
selinux_getenforce macro altogether).
Change-Id: I4de2f86fe2efe11a167e8a7d25dd799cefe482e5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
We were incorrectly reporting overlapping rules as duplicates.
Only report cases where an attribute-based rule is a superset
of type-based rule. Also omit self rules as they are often due
to expansion of domain self rules by checkpolicy.
Change-Id: I27f33cdf9467be5fdb6ce148aa0006d407291833
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Some device-specific policies are improperly creating a security
domain for logwrapper, rather than removing the logwrapper
lines from init.device.rc. Don't allow that. Explicitly add an entry
for /system/bin/logwrapper to force it to a system_file. Attempting
to override this will result in the following compile time error:
obj/ETC/file_contexts_intermediates/file_contexts: Multiple different
specifications for /system/bin/logwrapper
(u:object_r:logwrapper_exec:s0 and u:object_r:system_file:s0).
Bug: 15616899
Change-Id: Ia55394247a9fa16e00434d61091fff9d9d4ff125
Add missing services to service_contexts that we did not include
in earlier patch that added SELinux checks in service_manager.
Change-Id: I889d999bf0b745bfcb75a3553b207777dc5700b7
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.
Change-Id: I09e13839b1956f61875a38844fe4fc3c911ea60f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Prior to this change, the init and recovery domains were
allowed unrestricted use of context= mount options to force
all files within a given filesystem to be treated as having a
security context specified at mount time. The context= mount
option can be used in device-specific fstab.<board> files
to assign a context to filesystems that do not support labeling
such as vfat where the default label of sdcard_external is not
appropriate (e.g. /firmware on hammerhead).
Restrict the use of context= mount options to types marked with the
contextmount_type attribute, and then remove write access from
such types from unconfineddomain and prohibit write access to such
types via neverallow. This ensures that the no write to /system
restriction cannot be bypassed via context= mount.
Change-Id: I4e773fadc9e11328d13a0acec164124ad6e840c1
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
When applying a file based OTA, the recovery scripts sometimes
transiently label a directory as an exec_type. This occurs on
hammerhead when the OTA generation scripts generate lines of the
form:
set_metadata_recursive("/system/vendor/bin", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:vss_exec:s0");
set_metadata("/system/vendor/bin", "uid", 0, "gid", 2000, "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
which has the effect of transiently labeling the /system/vendor/bin
directory as vss_exec.
Allow this behavior for now, even though it's obviously a bug.
Also, allow recovery to read through the /dev directory.
Addresses the following denials:
avc: denied { read } for pid=143 comm="recovery" name="/" dev="tmpfs" ino=8252 scontext=u:r:recovery:s0 tcontext=u:object_r:device:s0 tclass=dir
avc: denied { open } for pid=143 comm="recovery" name="/" dev="tmpfs" ino=8252 scontext=u:r:recovery:s0 tcontext=u:object_r:device:s0 tclass=dir
avc: denied { relabelto } for pid=142 comm="update_binary" name="bin" dev="mmcblk0p25" ino=1438 scontext=u:r:recovery:s0 tcontext=u:object_r:vss_exec:s0 tclass=dir
avc: denied { getattr } for pid=142 comm="update_binary" path="/system/vendor/bin" dev="mmcblk0p25" ino=1438 scontext=u:r:recovery:s0 tcontext=u:object_r:vss_exec:s0 tclass=dir
avc: denied { setattr } for pid=142 comm="update_binary" name="bin" dev="mmcblk0p25" ino=1438 scontext=u:r:recovery:s0 tcontext=u:object_r:vss_exec:s0 tclass=dir
avc: denied { relabelfrom } for pid=142 comm="update_binary" name="bin" dev="mmcblk0p25" ino=1438 scontext=u:r:recovery:s0 tcontext=u:object_r:vss_exec:s0 tclass=dir
Bug: 15575013
Change-Id: I743bea356382d3c23c136465dc5b434878370127
These are no longer necessary after the clatd change to acquire
membership in AID_VPN when dropping root privileges.
Change-Id: I9955296fe79e6dcbaa12acad1f1438e11d3b06cf
This is no longer required now that clatd has switched from IPv6
forwarding to sockets.
Bug: 15340961
Change-Id: Id7d503b842882d30e6cb860ed0af69ad4ea3e62c
8670305177 wasn't complete. I thought
getattr on the directory wasn't needed but I was wrong. Not sure
how I missed this.
Addresses the following denial:
<4>[ 40.699344] type=1400 audit(15795140.469:9): avc: denied { getattr } for pid=1087 comm="system_server" path="/data/dalvik-cache/profiles" dev="mmcblk0p28" ino=105874 scontext=u:r:system_server:s0 tcontext=u:object_r:dalvikcache_profiles_data_file:s0 tclass=dir
Change-Id: Ibc176b2b00083bafaa91ab78d0f8dc1ca3c208b6
run-as won't communicate with shell via pipes. Allow it.
nnk@nnk:~$ adb shell "cat /dev/zero | run-as com.google.foo sh -c 'cat'"
/system/bin/sh: cat: <stdout>: Broken pipe
<4>[ 1485.483517] type=1400 audit(1402623577.085:25): avc: denied { read } for pid=6026 comm="run-as" path="pipe:[29823]" dev="pipefs" ino=29823 scontext=u:r:runas:s0 tcontext=u:r:shell:s0 tclass=fifo_file
read is definitely needed. Not sure about write, but adding it just
in case.
Change-Id: Ifdf838b0df79a5f1e9559af57c2d1fdb8c41a201
