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>
Newer adbd versions use functionfs instead of a custom adb usb gadget.
Make sure the functionfs filesystem is properly labeled, and that adbd
has access to the functionfs files.
Once labeled, this addresses the following denials:
<12>[ 16.127191] type=1400 audit(949060866.189:4): avc: denied { read write } for pid=223 comm="adbd" name="ep0" dev="functionfs" ino=5489 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
<12>[ 16.127406] type=1400 audit(949060866.189:5): avc: denied { open } for pid=223 comm="adbd" path="/dev/usb-ffs/adb/ep0" dev="functionfs" ino=5489 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
<12>[ 377.366011] type=1400 audit(949061227.419:16): avc: denied { ioctl } for pid=225 comm="adbd" path="/dev/usb-ffs/adb/ep2" dev="functionfs" ino=5564 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
Change-Id: Iee8b522e48b4d677fd12f7c83dbc7ffbc9543ad2
Addresses denials seen when attempting to take a screencaputre from ddms:
<5>[ 1232.327360] type=1400 audit(1393354131.695:41): avc: denied { read write } for pid=18487 comm="screencap" name="nvhost-ctrl" dev="tmpfs" ino=4035 scontext=u:r:adbd:s0 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
Bug: 13188914
Change-Id: I758e4f87ab024035604d47eebae7f89f21ea1e3e
This should be obsoleted by the restorecon in
I30e4d2a1ae223a03eadee58a883c79932fff59fe .
Change-Id: Iaeacb1b720b4ac754c6b9baa114535adc1494df2
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
adbd was only in enforcing for user builds. Commit
Ib33c0dd2dd6172035230514ac84fcaed2ecf44d6 allows us to move
it into enforcing for everyone. Do it.
Change-Id: Ie1a3e5361c891d2c9366e11f35699e3146cc3d88
When adbd runs as root, it transitions into the
su domain. Add the various rules to support this.
This is needed to run the adbd and shell domains in
enforcing on userdebug / eng devices without breaking
developer workflows.
Change-Id: Ib33c0dd2dd6172035230514ac84fcaed2ecf44d6
adbd uses setpcap to drop capabilities from the bounding
set on user builds. See system/core commit
080427e4e2b1b72718b660e16b6cf38b3a3c4e3f
Change-Id: I6aec8d321b8210ea50a56aeee9bc94738514beab
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>
Confine run-as (but leave permissive for now) and add
other allow rules required for the use of run-as and ndk-gdb
functionality.
Change-Id: Ifae38233c091cd34013e98830d72aac4c4adcae0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This change removes the permissive line from unconfined
domains. Unconfined domains can do (mostly) anything, so moving
these domains into enforcing should be a no-op.
The following domains were deliberately NOT changed:
1) kernel
2) init
In the future, this gives us the ability to tighten up the
rules in unconfined, and have those tightened rules actually
work.
When we're ready to tighten up the rules for these domains,
we can:
1) Remove unconfined_domain and re-add the permissive line.
2) Submit the domain in permissive but NOT unconfined.
3) Remove the permissive line
4) Wait a few days and submit the no-permissive change.
For instance, if we were ready to do this for adb, we'd identify
a list of possible rules which allow adbd to work, re-add
the permissive line, and then upload those changes to AOSP.
After sufficient testing, we'd then move adb to enforcing.
We'd repeat this for each domain until everything is enforcing
and out of unconfined.
Change-Id: If674190de3262969322fb2e93d9a0e734f8b9245
The /adb_keys entry will only take effect if a restorecon is
applied by init.rc on a kernel that includes the rootfs labeling
support, but does no harm otherwise.
The /data/misc/adb labeling ensures correct labeling of the adb_keys
file created if the device has ro.adb.secure=1 set.
Allow adbd to read the file.
Change-Id: I97b3d86a69681330bba549491a2fb39df6cf20ef
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This prevents denials from being generated by the base policy.
Over time, these rules will be incrementally tightened to improve
security.
Change-Id: I4be1c987a5d69ac784a56d42fc2c9063c402de11
Read access to /dev/log/* is no longer restricted.
Filtering on reads is performed per-uid by the kernel logger driver.
Change-Id: Ia986cbe66b84f3898e858c60f12c7f3d63ac47cf
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Update policy for Android 4.2 / latest master.
Primarily this consists of changes around the bluetooth subsystem.
The zygote also needs further permissions to set up /storage/emulated.
adbd service now gets a socket under /dev/socket.
keystore uses the binder.
Change-Id: I8c5aeb8d100313c75169734a0fa614aa974b3bfc
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
