x_file_perms and friends allow execve; we only want to permit
mmap/mprotect PROT_EXEC here.
Change-Id: I780f202c357f4611225cec25fda5cb9d207e085f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
We do not want to permit connecting to arbitrary unconfined services
left running in the init domain. I do not know how this was originally
triggered and thus cannot test that it is fixed. Possible causes:
- another service was left running in init domain, e.g. dumpstate,
- there was a socket entry for the service in the init.rc file
and the service was launched via logwrapper and therefore init did
not know how to label the socket.
The former should be fixed. The latter can be solved either by
removing use of logwrapper or by specifying the socket context
explicitly in the init.rc file now.
Change-Id: I09ececaaaea2ccafb7637ca08707566c1155a298
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
From the commit that added these rules, this appears to have been
an artifact of having dumpstate running in the init domain.
Change-Id: Iec2b9c3f5673d0e2cce9a0bf297e23555c423e87
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Just use notdevfile_class_set to pick up all non-device file classes.
Change-Id: Ib3604537ccfc25da67823f0f2b5d70b84edfaadf
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Otherwise all domains can create/write files that are executable
by all other domains. If I understand correctly, this should
only be necessary for app domains executing content from legacy
unlabeled userdata partitions on existing devices and zygote
and system_server mappings of dalvikcache files, so only allow
it for those domains.
If required for others, add it to the individual
domain .te file, not for all domains.
Change-Id: I6f5715eb1ecf2911e70772b9ab4e531feea18819
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow system_server to unlink sockets created
by the wpa supplicant. This will resolve the following
denial seen across mutliple devices.
avc: denied { unlink } for pid=584 comm="WifiStateMachin" name="wlan0" dev=mmcblk0p10 ino=138762 scontext=u:r:system_server:s0 tcontext=u:object_r:wpa_socket:s0 tclass=sock_file
Change-Id: If3a8b1f270dfcd3dc6838eb8ac72e3d5004cc36d
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
On manta, the keystore CTS tests are failing, because
keystore isn't allowed to talk to the tee. Allow it.
I've only seen this bug on manta, but it seems appropriate
for all domains.
Fixes the following denial:
<5>[ 286.249563] type=1400 audit(1389210059.924:6): avc: denied { connectto } for pid=126 comm="keystore" path=006D636461656D6F6E scontext=u:r:keystore:s0 tcontext=u:r:tee:s0 tclass=unix_stream_socket
Bug: 12450710
Change-Id: I07133d9abeaf967392118ba478a5a391cf0c5fa5
When playing protected content on manta, surfaceflinger would crash.
STEPS TO REPRODUCE:
1. Launch Play Movies & TV
2. Play any movie and observe
OBSERVED RESULTS:
Device reboot while playing movies
EXPECTED RESULTS:
No device reboot
Even though this only reproduces on manta, this seems appropriate
for a general policy.
Addresses the following denials:
<5>[ 36.066819] type=1400 audit(1389141624.471:9): avc: denied { write } for pid=1855 comm="TimedEventQueue" name="tlcd_sock" dev="mmcblk0p9" ino=627097 scontext=u:r:mediaserver:s0 tcontext=u:object_r:drmserver_socket:s0 tclass=sock_file
<5>[ 36.066985] type=1400 audit(1389141624.471:10): avc: denied { connectto } for pid=1855 comm="TimedEventQueue" path="/data/app/tlcd_sock" scontext=u:r:mediaserver:s0 tcontext=u:r:drmserver:s0 tclass=unix_stream_socket
<5>[ 41.379708] type=1400 audit(1389141629.786:15): avc: denied { connectto } for pid=120 comm="surfaceflinger" path=006D636461656D6F6E scontext=u:r:surfaceflinger:s0 tcontext=u:r:tee:s0 tclass=unix_stream_socket
<5>[ 41.380051] type=1400 audit(1389141629.786:16): avc: denied { read write } for pid=120 comm="surfaceflinger" name="mobicore-user" dev="tmpfs" ino=4117 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tee_device:s0 tclass=chr_file
<5>[ 41.380209] type=1400 audit(1389141629.786:17): avc: denied { open } for pid=120 comm="surfaceflinger" name="mobicore-user" dev="tmpfs" ino=4117 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tee_device:s0 tclass=chr_file
<5>[ 41.380779] type=1400 audit(1389141629.786:18): avc: denied { ioctl } for pid=120 comm="surfaceflinger" path="/dev/mobicore-user" dev="tmpfs" ino=4117 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tee_device:s0 tclass=chr_file
Change-Id: I20286ec2a6cf0d190a84ad74e88e94468bab9fdb
Bug: 12434847
/data/mediadrm is appearing on devices but is
receiving the system_data_file type. Use the
media_data_file label to help classify these files.
This new label will help with the following denials.
with exisiting allow rules for mediaserver are already
in place.
type=1400 msg=audit(1389139139.551:308): avc: denied { open } for pid=179 comm="mediaserver" name="ay64.dat" dev="mmcblk0p23" ino=136819 scontext=u:r:mediaserver:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
type=1400 msg=audit(1389139140.783:309): avc: denied { read } for pid=179 comm="mediaserver" name="IDM1013" dev="mmcblk0p23" ino=136818 scontext=u:r:mediaserver:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir
type=1400 msg=audit(1389139140.783:310): avc: denied { open } for pid=179 comm="mediaserver" name="IDM1013" dev="mmcblk0p23" ino=136818 scontext=u:r:mediaserver:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir
Change-Id: I84ac78517fdbb0264cf07379120a62675505fc95
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Exclude execute from the rules allowing access to files,
and only add it back for the rootfs and files labeled
with system_file (/system, /vendor) or one of the types in exec_type
(files under /system that cause domain transitions).
Change-Id: Ic72d76dc92e79bcc75a38398425af3bb1274a009
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
They serve no purpose; these directories/files are normally accessible
in the same way as the rest of /system. Also one of them has the wrong
attributes (data_file_type), thereby making it writable by some domains,
and under current policy, shell and apps cannot do ls -l /etc/ppp /etc/dhcpcd.
Change-Id: I0c1baa434fe78373684f4eaab40a41fddf2bdd79
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This ensures that only domains that are explicitly allowed executable
memory permissions are granted them.
Unconfined domains retain full write + execute access to all file
types. A further change could possibly restrict execute access to
a subset of file types, e.g. system_file + exec_type.
Change-Id: I842f5a2ac5921cc2bd0ab23a091eb808fdd89565
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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>
/proc/sys/net could use its own type to help distinguish
among some of the proc access rules. Fix dhcp and netd
because of this.
Change-Id: I6e16cba660f07bc25f437bf43e1eba851a88d538
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
ping in Android no longer requires any additional privileges beyond
the caller. Drop the ping domain and executable file type entirely.
Also add net_domain() to shell domain so that it can create and
use network sockets.
Change-Id: If51734abe572aecf8f510f1a55782159222e5a67
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
There are continued complaints about not being able to generate
bug reports and surfaceflinger crashes. Move surfaceflinger
out of enforcing until I can resolve this.
Here are some denials I'm seeing. I'm not sure what binder service is
running in the shell domain... Need to do more digging.
nnk@nnk:~/Downloads$ grep "avc: " screenshot_runtime_restart.txt | grep surfaceflinger
<5>[ 5.182699] type=1400 audit(1389111729.860:9): avc: denied { search } for pid=186 comm="surfaceflinger" name="tmp" dev="mmcblk0p28" ino=627090 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:shell_data_file:s0 tclass=dir
<5>[ 744.988702] type=1400 audit(1389112469.578:188): avc: denied { call } for pid=596 comm="Binder_3" scontext=u:r:surfaceflinger:s0 tcontext=u:r:shell:s0 tclass=binder
This reverts commit a11c56e124.
Bug: 12416329
Change-Id: I7b72608c760c4087f73047ad751a5bd069fa2ec7
Causing adbd to run at 100% cpu utilization when the following
sequence of commands are run:
1) Run the command "adb shell ping -c 1 -w 5 www.google.com" for 5 times
2) Run "adb shell top -m 5"
The following denial occurs:
<5>[ 20.647559] type=1400 audit(1389054327.861:21): avc: denied { sigchld } for pid=1989 comm="adbd" scontext=u:r:ping:s0 tcontext=u:r:adbd:s0 tclass=process
Reverting for now.
This reverts commit 1b556c3270.
Bug: 12251052
Change-Id: I1b9920624f49b0aed2226c41a45005aff228d9e8
When a bugreport is triggered using the device keys,
it generates a screenshot and places it into
/data/data/com.android.shell/files/bugreports. SELinux is denying
those writes.
Addresses the following denials:
<5> type=1400 audit(1389047451.385:23): avc: denied { call } for pid=267 comm="Binder_1" scontext=u:r:surfaceflinger:s0 tcontext=u:r:dumpstate:s0 tclass=binder
<5> type=1400 audit(1389046083.780:37): avc: denied { write } for pid=4191 comm="dumpsys" path="/data/data/com.android.shell/files/bugreports/bugreport-2014-01-06-14-07-35.txt.tmp" dev="mmcblk0p28" ino=81874 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:shell_data_file:s0 tclass=file
Bug: 12416329
Change-Id: I318145591cda500094d98103d30b784df48a67be
init can't handle binder calls. It's always incorrect
to allow init:binder call, and represents a binder call
to a service without an SELinux domain. Adding this
allow rule was a mistake; the dumpstate SELinux domain didn't
exist at the time this rule was written, and dumpstate was
running under init's domain.
Add a neverallow rule to prevent the reintroduction of
this bug.
Change-Id: I78d35e675fd142d880f15329471778c18972bf50
tmpfs_domain() macro defines a per-domain type and
allows access for tmpfs-backed files, including ashmem
regions. execute-related permissions crept into it,
thereby allowing write + execute to ashmem regions for
most domains. Move the execute permission out of tmpfs_domain()
to app_domain() and specific domains as required.
Drop execmod for now we are not seeing it.
Similarly, execute permission for /dev/ashmem crept into
binder_use() as it was common to many binder using domains.
Move it out of binder_use() to app_domain() and specific domains
as required.
Change-Id: I66f1dcd02932123eea5d0d8aaaa14d1b32f715bb
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
execmem permission controls the ability to make an anonymous
mapping executable or to make a private file mapping writable
and executable. Remove this permission from domain (i.e.
all domains) by default, and add it explicitly to app domains.
It is already allowed in other specific .te files as required.
There may be additional cases in device-specific policy where
it is required for proprietary binaries.
Change-Id: I902ac6f8cf2e93d46b3a976bc4dabefa3905fce6
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
system_server and app domains need to map dalvik-cache files with PROT_EXEC.
type=1400 msg=audit(13574814.073:132): avc: denied { execute } for pid=589 comm="system_server" path="/data/dalvik-cache/system@priv-app@SettingsProvider.apk@classes.dex" dev="mmcblk0p30" ino=684132 scontext=u:r:system_server:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
Apps need to map cached dex files with PROT_EXEC. We already allow this
for untrusted_app to support packaging of shared objects as assets
but not for the platform app domains.
type=1400 audit(1387810571.697:14): avc: denied { execute } for pid=7822 comm="android.youtube" path="/data/data/com.google.android.youtube/cache/ads1747714305.dex" dev="mmcblk0p30" ino=603259 scontext=u:r:platform_app:s0 tcontext=u:object_r:platform_app_data_file:s0 tclass=file
Change-Id: I309907d591ea6044e3e6aeb57bde7508e426c033
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Will likely want to split into adbd_user.te vs adbd.te before
going enforcing to support adb root and adb remount on non-user builds.
Possibly take all common rules to an adbdcommon.te.
Change-Id: I63040c7f5f0fca10b3df682572c51c05e74738a7
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
During removing cache data using Zipper application, I found violation logs.
avc: denied { write } for pid=198 comm="installd" name="cache" dev="mmcblk0p29" ino=81680 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=dir
avc: denied { remove_name } for pid=198 comm="installd" name="downloadfile.apk" dev="mmcblk0p29" ino=82247 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=dir
avc: denied { unlink } for pid=198 comm="installd" name="downloadfile.apk" dev="mmcblk0p29" ino=82247 scontext=u:r:installd:s0 tcontext=u:object_r:download_file:s0 tclass=file
Reproduction path is like below
1. Downloading Zipper application from Google Play (I used Zipper 1.9.9.2)
2. Clicking option and clicking "removing cache" button
3. Select "yes"
4. Violation show up
Change-Id: I7993f1d20e3aa4c3e19c4aba9b4bef6760831a87
This showed up at some point in the past during our own
internal CTS testing but it seems wrong based on the DAC
permissions and a potential way to inject code into apps
from the shell. Drop it for now and see if it shows up again.
This predates userdebug/eng vs user shell split so possibly
it only happens in the userdebug/eng case.
Change-Id: If8b1e7817f8efecbf68a0ba5fd06328a23a6c6db
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
