This adds neverallow rules which enforce the prohibition on
communication between framework and vendor components over VendorBinder.
This prohibition is similar in spirit to the one for Binder
communications.
Most changes consist of adding neverallow rules, which do not affect
runtime behavior. The only change which does affect runtime behavior
is the change which takes away the right of servicemanager domain to
transfer Binder tokens to hwservicemanager and vndservicemanager. This
grant was there by accident (because it was overly broad) and is not
expected to be needed: servicemanager, hwservicemanager, and
vndservicemanager are not supposed to be communicating with each
other.
P. S. The new neverallow rules in app_neverallows.te are covered by
the new rules in domain.te. The rules were nevertheless added to
app_neverallows.te for consistency with other *Binder rules there.
Test: mmm system/sepolicy
Bug: 37663632
Change-Id: I7c2ae23924bf0f2fed3f1e3a8d4d603129286329
App domains which host arbitrary code must not have access to
arbitrary HwBinder services. Such access unnecessarily increases the
attack surface. The reason is twofold:
1. HwBinder servers do not perform client authentication because HIDL
currently does not expose caller UID information and, even if it
did, many HwBinder services either operate at a layer below that of
apps (e.g., HALs) or must not rely on app identity for
authorization. Thus, to be safe, the default assumption is that
a HwBinder service treats all its clients as equally authorized to
perform operations offered by the service.
2. HAL servers (a subset of HwBinder services) contain code with
higher incidence rate of security issues than system/core
components and have access to lower layes of the stack (all the way
down to hardware) thus increasing opportunities for bypassing the
Android security model.
HwBinder services offered by core components (as opposed to vendor
components) are considered safer because of point #2 above.
Always same-process aka always-passthrough HwBinder services are
considered safe for access by these apps. This is because these HALs
by definition do not offer any additional access beyond what its
client already as, because these services run in the process of the
client.
This commit thus introduces these two categories of HwBinder services
in neverallow rules.
Test: mmm system/sepolicy -- this does not change on-device policy
Bug: 34454312
Change-Id: I4f5f4dd10b3fc3bb9d262dda532d4a23dcdf061d
This adds fine-grained policy about who can register and find which
HwBinder services in hwservicemanager.
Test: Play movie in Netflix and Google Play Movies
Test: Play video in YouTube app and YouTube web page
Test: In Google Camera app, take photo (HDR+ and conventional),
record video (slow motion and normal), and check that photos
look fine and videos play back with sound.
Test: Cast screen to a Google Cast device
Test: Get location fix in Google Maps
Test: Make and receive a phone call, check that sound works both ways
and that disconnecting the call frome either end works fine.
Test: Run RsHelloCompute RenderScript demo app
Test: Run fast subset of media CTS tests:
make and install CtsMediaTestCases.apk
adb shell am instrument -e size small \
-w 'android.media.cts/android.support.test.runner.AndroidJUnitRunner'
Test: Play music using Google Play music
Test: Adjust screen brightness via the slider in Quick Settings
Test: adb bugreport
Test: Enroll in fingerprint screen unlock, unlock screen using
fingerprint
Test: Apply OTA update:
Make some visible change, e.g., rename Settings app.
make otatools && \
make dist
Ensure device has network connectivity
ota_call.py -s <serial here> --file out/dist/sailfish-ota-*.zip
Confirm the change is now live on the device
Bug: 34454312
(cherry picked from commit 632bc494f1)
Merged-In: Iecf74000e6c68f01299667486f3c767912c076d3
Change-Id: I7a9a487beaf6f30c52ce08e04d415624da49dd31
installd needs to check whether idmap is outdated or not compared to
vendor overlay file.
Test: building succeeded and tested on sailfish.
Bug: 37179531
Change-Id: I934c1ae39e3f806bca1e3d68cf8190addeebb499
Remove neverallow exemption allowing other processes to run in
the bluetooth app's selinux domain.
The bluetooth domain is intended to host the zygote spawned
bluetooth app. It is not intended to host other bluetooth related
processes. Please define new domains for these processes.
Test: build Marlin
Change-Id: I1fd3dd0fe85f73457d77b63a65b4307821cbd41c
vndservicemanager is a copy of servicemanager, and so has the exact
same properties. This should be reflected in the sharing of an object
manager in SELinux policy, rather than creating a second one, which is
effectively an attempt at namespacing based on object rather than type
labels. hwservicemanager, however, provides different and additional
functionality that may be reflected in changed permissions, though they
currently map to the existing servicemanager permissions. Keep the new
hwservice_manager object manager but remove the vndservice_manager one.
Bug: 34454312
Bug: 36052864
Test: policy builds and device boots.
Change-Id: I9e0c2757be4026101e32ba780f1fa67130cfa14e
Temporary attribute (checked against in CTS) to point out vendor
processes that run /system executables. These are currently only down to
2-3 of them that are related to telephony on sailfish
Bug: 36463595
Test: Build succeeds for sailfish
Test: ./cts-tradefed run cts -m CtsSecurityHostTestCases -t \
android.security.cts.SELinuxHostTest#testNoExemptionsForVendorExecutingCore \
--skip-device-info --skip-preconditions --skip-connectivity-check \
--abi arm64-v8a
Change-Id: I9eb40ad259aefba73869d6a1b40186d33fa475dd
Signed-off-by: Sandeep Patil <sspatil@google.com>
Bug: 36463595
Test: Boot sailfish, make wifi call, internet over data and wifi
Change-Id: I81259b6412d7197725afe2fe4976aa0a03b8df6e
Signed-off-by: Sandeep Patil <sspatil@google.com>
* changes:
suppress audit logs from rild's access to core domain through system()
sepolicy: auditallow vendor components to execute files from /system
vendor_shell: add sepolicy for vendor shell
toolbox: add sepolicy for vendor toybox
Do not allow priv_apps to scan all exec files
Adds a rule to audit vendor domains from executing programs from /system
with the exception of domains whitelisted in the rule.
Bug: 36463595
Test: Boot sailfish
Test: Run SELinuxHostTests with the tests that checks for new violators
(without the API check) to ensure it fails for sailfish. The API
check will allow the test to skip the check.
Change-Id: Id19f32141bceba4db4bd939394ff3ee0b3c4b437
Signed-off-by: Sandeep Patil <sspatil@google.com>
Bug: 36463595
Test: Boot sailfish and make sure all vendor services that are shell scripts
work. (Checke exited status)
Change-Id: I3d1d564114a914dec8179fb93a9e94493c2808da
Signed-off-by: Sandeep Patil <sspatil@google.com>
This unbreaks user builds broken by recently landed changes to secilc
which is now aggressively removing attributes which aren't used in
allow rules, even when they are used in other places, such as being
referenced from *_contexts files.
User builds are broken by vndservice_manager_type not being found when
checkfc is run for *vndservice_contexts targets.
Test: On a clean user build: mmma system/sepolicy
Bug: 37319524
Bug: 36508258
Change-Id: I4a1727a74122ecd9020c3831462d56a65ee6d304
hwservicemanager can check hwservice_contexts files
both from the framework and vendor partitions.
Initially, have a wildcard '*' in hwservice_contexts
that maps to a label that can be added/found from
domain. This needs to be removed when the proper policy
is in place.
Also, grant su/shell access to hwservicemanager list
operations, so tools like 'lshal' continue to work.
Bug: 34454312
Test: Marlin boots
Change-Id: I3a02d97a82458692b528d85c1b8e78b6f82ea1bc
Follow-up to commit 1b5f81a2d2.
Bug: 36681210
Bug: 37158297
Test: lunch sailfish-userdebug && m
Test: Manually run OTA
Change-Id: Ifb4808c9255842a51a660c07ffd924cef52024c5
The kernel modules under /vendor partition has been relabeled to vendor_file.
This CL allows for the modprobe to load modules labeled vendor_file.
Kernel modules are loaded in init.rc with following commands:
exec u:r:modprobe:s0 -- /system/bin/modprobe -d /vendor/lib/modules MODULE
Bug: 35653245
Test: tested on sailfish
Change-Id: I2132ca4de01c5c60476dad8496e98266de5a1bb7
Renderscript drivers are loaded from /vendor/lib64 by following the
/system/vendor symlink. This change fixes a couple of things.
- Allows all domains access to follow the symlink
- Restores app domain permissions for /vendor for non-treble devices
- Allow app domains to peek into /vendor/lib64, but NOT grant 'execute'
permissions for everything. Since RS drivers can be loaded into any
process, their vendor implementation and dependencies have been
marked as 'same process HALs' already.
Bug: 37169158
Test: Tested on sailfish (Treble) & Angler (non-treble)
./cts-tradefed run cts -m CtsRenderscriptTestCases \
--skip-device-info --skip-preconditions --skip-connectivity-check \
--abi arm64-v8a
Result: Tests Passed: 743 Tests Failed: 0
Change-Id: I36f5523381428629126fc196f615063fc7a50b8e
Signed-off-by: Sandeep Patil <sspatil@google.com>
The concept of VNDK-stable set is gone because they no longer need to be
stable across several Android releases. Instead, they are just small set
of system libraries (other than Low-Level NDK) that can be used by
same-process HALs. They need to be stable only during an Android release
as other VNDK libraries. However, since they are eligible for double
loading, we still need to distinguish those libs from other VNDK
libraries. So we give them a name vndk-sp, which means VNDK designed for
same-process HALs.
Bug: 37139956
Test: booting successful with vndk-sp libs in /vendor/lib(64)?/vndk-sp
Change-Id: I892c4514deb3c6c8006e3659bed1ad3363420732
Vndk-stable libs are system libs that are used by same process HALs.
Since same process HALs can be loaded to any process, so are vndk-stable
libs.
Bug: 37138502
Test: none, because the directory is currently empty and thus this is
no-op. sailfish builds and boots.
Change-Id: I67a2c8c2e4c3517aa30b4a97dc80dc2800e47b5a
Effectively removes TODOs and finalizes the initial solution to allow
all domains access to 'vendor_file'.
Bug: 36681074
Test: Build and boot sailfish (no policy changes in the CL)
Change-Id: I50c05e20175c5273b34901809d967dd3e48bdb0e
Signed-off-by: Sandeep Patil <sspatil@google.com>
All accesses to /vendor/app within platform include permissions to read
symlinks in the location. This rule is redundant now.
Bug: 36806861
Test: Boot sailfish and find no denials for 'vendor_app_file'
Change-Id: Ic17a67521cff6717d83b78bb4ad8e21e772f6d4f
Signed-off-by: Sandeep Patil <sspatil@google.com>
/vendor/framework is now designated location for vendor's platform
libraries. The directory is thus only made available for 'dex2oat'
coredomain.
Bug: 36680116
Test: Boot sailfish & angler and launch gApps, dialer w/ no denials for
'vendor_framework_file'
Change-Id: I24c2ec30f836330005a972ae20d839bef9dcb8aa
Signed-off-by: Sandeep Patil <sspatil@google.com>
The change makes 'vendor_overlay_file' accessible only to few platform
domains like idmap, system_server, zygote and appdomain.
The overlay files contains RROs (runtime resource overlays)
Bug: 36681210
Test: Boot sailfish (treble device) from wiped flashall
Test: Connect to wifi and launch chrome to load few websites.
Test: Launch camera and record + playback video
Change-Id: I3596ca89ad51d0e7d78c75121f22ea71209ee332
Signed-off-by: Sandeep Patil <sspatil@google.com>
The change makes 'vendor_app_file' accessible only to few platform
domains like dex2oat, idmap, installd, system_server and appdomain.
Bug: 36681210
Test: Boot sailfish (treble device) from wiped flashall
Test: Connect to wifi and launch chrome to load few websites.
Test: Launch camera and record + playback video
Change-Id: Ib8757fedbf2e19c8381c8cd0f8f2693b2345534b
Signed-off-by: Sandeep Patil <sspatil@google.com>
The CL splits /vendor labeling from /system. Which was allowing all
processes read, execute access to /vendor.
Following directories will remain world readable
/vendor/etc
/vendor/lib(64)/hw/
Following are currently world readable but their scope
will be minimized to platform processes that require access
/vendor/app
/vendor/framework/
/vendor/overlay
Files labelled with 'same_process_hal_file' are allowed to be
read + executed from by the world. This is for Same process HALs and
their dependencies.
Bug: 36527360
Bug: 36832490
Bug: 36681210
Bug: 36680116
Bug: 36690845
Bug: 36697328
Bug: 36696623
Bug: 36806861
Bug: 36656392
Bug: 36696623
Bug: 36792803
All of the tests were done on sailfish, angler, bullhead, dragon
Test: Boot and connect to wifi
Test: Run chrome and load websites, play video in youtube, load maps w/
current location, take pictures and record video in camera,
playback recorded video.
Test: Connect to BT headset and ensure BT audio playback works.
Test: OTA sideload using recovery
Test: CTS SELinuxHostTest pass
Change-Id: I278435b72f7551a28f3c229f720ca608b77a7029
Signed-off-by: Sandeep Patil <sspatil@google.com>
Add selinux policies for init script and shell script to unzip a tar
containing ASAN libraries on boot.
Bug: 36458146
Test: m && m SANITIZE_TARGET=address
Test: manual (build steps for tar missing)
Change-Id: I5c3cb233aae93ee9985431090af902b0e3c1b0a7
(cherry picked from commit 0b74305011)
Merged-In: I5c3cb233aae93ee9985431090af902b0e3c1b0a7
Vendor and system components are only allowed to share files by
passing open FDs over HIDL. Ban all directory access and all file
accesses other than what can be applied to an open FD such as
ioctl/stat/read/write/append.
This commit asserts that core components marked with attribute
coredomain may only access core data types marked with attribute
core_data_file_type.
A temporary exemption is granted to domains that currently rely on
access.
(cherry picked from commit cd97e71084)
Bug: 34980020
Test: build Marlin policy
Change-Id: I2f0442f2628fbac1f2f7aa5ddf2a13e16b2546cc
/data/misc/zoneinfo is provided by libc and is considered to be
VNDK stable. Grant read access to all domains and exempt from
neverallow rules asserting no vendor access to core data types.
Bug: 36730929
Test: Marlin Policy builds
Change-Id: I13766a661d6314f5393639fc20f1ab55d802f35f
This futher restricts neverallows for sockets which may be exposed as
filesystem nodes. This is achieved by labelling all such sockets
created by core/non-vendor domains using the new coredomain_socket
attribute, and then adding neverallow rules targeting that attribute.
This has now effect on what domains are permitted to do. This only
changes neverallow rules.
Test: mmm system/sepolicy
Bug: 36577153
(cherry picked from commit cf2ffdf0d8)
Change-Id: Iffeee571a2ff61fb9515fa6849d060649636524e
This tightens neverallows for looking up Binder servicemanager
services from vendor components. In particular, vendor components,
other than apps, are not permitted to look up any Binder services.
Vendor apps are permitted to look up only stable public API services
which is exactly what non-vendor apps are permitted to use as well.
If we permitted vendor apps to use non-stable/hidden Binder services,
they might break when core components get updated without updating
vendor components.
Test: mmm system/sepolicy
Bug: 35870313
Change-Id: I47d40d5d42cf4205d9e4e5e5f9d0794104efc28f
This tightens neverallows for looking up Binder servicemanager
services from vendor components. In particular, vendor components,
other than apps, are not permitted to look up any Binder services.
Vendor apps are permitted to look up only stable public API services
which is exactly what non-vendor apps are permitted to use as well.
If we permitted vendor apps to use non-stable/hidden Binder services,
they might break when core components get updated without updating
vendor components.
Test: mmm system/sepolicy
Bug: 35870313
Change-Id: I949d62b3528cadb4bfe6f5985c25d1f497df0d5a
We don't want to prevent access from vendor platform apps to system app
data. The issue with the referencing system_app explicitly in
neverallows is that vendor platform apps which need sandboxes similar to
system_app cannot be placed under system_app without modifying the
policy for all platform apps.
Test: mmm system/sepolicy
Change-Id: Ic0052602c31be4d74b02eeea129e2d8bfbd9c8d3
split property context file in vendor and sytem were left untouched by
the recent changes. This was working accidentally because they were
still accessible to all domains as 'system_file'.
Bug: 36002573
Test: Boot sailfish to observe no new denials.
Test: 'adb sideload' OTA on sailfish successfully
Change-Id: I5bec058b59db83d2a431e9f7e91c5a09af7d2942
Signed-off-by: Sandeep Patil <sspatil@google.com>
Vendor and system components are only allowed to share files by
passing open FDs over HIDL. Ban all directory access and all file
accesses other than what can be applied to an open file:
stat/read/write/append.
This commit marks core data types as core_data_file_type and bans
access to non-core domains with an exemption for apps. A temporary
exemption is also granted to domains that currently rely on
access with TODOs and bug number for each exemption.
Bug: 34980020
Test: Build and boot Marlin. Make phone call, watch youtube video.
No new denials observed.
Change-Id: I320dd30f9f0a5bf2f9bb218776b4bccdb529b197
In f5446eb148 I forgot to let violators
of "no Binder in vendor" rule keep their access to /dev/binder. This
commit fixes the issue.
Test: mmm system/sepolicy
Bug: 35870313
Bug: 36657020
Change-Id: I3fc68df1d78e2a2da94ac9bf036a51923e3a9aae
On PRODUCT_FULL_TREBLE devices, non-vendor domains (coredomain) and
vendor domain are not permitted to connect to each other's sockets.
There are two main exceptions: (1) apps are permitted to talk to other
apps over Unix domain sockets (this is public API in Android
framework), and (2) domains with network access (netdomain) are
permitted to connect to netd.
This commit thus:
* adds neverallow rules restricting socket connection establishment,
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"socket_between_core_and_vendor_violators" attribute. The attribute
is needed because the types corresponding to violators are not
exposed to the public policy where the neverallow rules are.
Test: mmm system/sepolicy
Bug: 36613996
Change-Id: I458f5a09a964b06ad2bddb52538ec3a15758b003
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor
apps) are not permitted to use Binder. This commit thus:
* groups non-vendor domains using the new "coredomain" attribute,
* adds neverallow rules restricting Binder use to coredomain and
appdomain only, and
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"binder_in_vendor_violators" attribute. The attribute is needed
because the types corresponding to violators are not exposed to the
public policy where the neverallow rules are.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: In Chrome, navigate to ip6.me, play a YouTube video
Test: YouTube: play a video
Test: Netflix: play a movie
Test: Google Camera: take a photo, take an HDR+ photo, record video with
sound, record slow motion video with sound. Confirm videos play
back fine and with sound.
Bug: 35870313
Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
vndservicemanager is the context manager for binder services
that are solely registered and accessed from vendor processes.
Bug: 36052864
Test: vendorservicemanager runs
Merged-In: Ifbf536932678d0ff13d019635fe6347e185ef387
Change-Id: I430f1762eb83825f6cd4be939a69d46a8ddc80ff
perf_event_max_sample_rate is needed to be read for native profiling,
otherwise CTS test can fail on devices with kernel >= 4.4. Before this CL,
the file is not readable from untrusted_app domain. This CL makes it readable
from both shell domain and untrusted_app domain.
Bug: http://b/35554543
Test: build and test on marlin.
Change-Id: Id118e06e3c800b70a749ab112e07a4ec24bb5975
We need more time to investigate the effect that this change will
have on DRM solutions. Until the investigation is done, revert.
This reverts commit 38d3eca0d4.
Bug: 30146890
Bug: 20013628
Bug: 35323421
Change-Id: I5ad69ef5ee12081ce7fc0a8440712f7f8f77cf16
Test: policy compiles.
Drop support for execmod (aka text relocations) for newer API versions.
Retain it for older app APIs versions.
Bug: 30146890
Bug: 20013628
Bug: 35323421
Test: policy compiles.
Change-Id: Ie54fdb385e9c4bb997ad6fcb6cff74f7e32927bb
Addresses:
denied { getattr } for pid=155 comm="keystore" path="/vendor"
dev="mmcblk0p6" ino=1527 scontext=u:r:keystore:s0
tcontext=u:object_r:system_file:s0 tclass=lnk_file
On devices without an actual vendor image, /vendor is a symlink to
/system/vendor. When loading a library from this symlinked vendor,
the linker uses resolve_paths() resulting in an lstat(). This
generates an selinux denial. Allow this lstat() so that paths can
be resolved on devices without a real vendor image.
Bug: 35946056
Test: sailfish builds
Change-Id: Ifae11bc7039047e2ac2b7eb4fbcce8ac4580799f
Label /proc/sys/vm/mmap_rnd_bits so it is only readable and writable by
init. This also tightens the neverallow restrictions for proc_security.
Bug: 33563834
Test: run cts -m CtsPermissionTestCases -t \
android.permission.cts.FileSystemPermissionTest#testProcfsMmapRndBitsExistsAndSane
Change-Id: Ie7af39ddbf23806d4ffa35e7b19d30fec7b6d410
To determine if it is safe to run fsck on a filesystem, e2fsck
must first determine if the filesystem is mounted. To do that,
e2fsck scans through /proc/mounts and collects all the mounted
block devices. With that information, it runs stat() on each block
device, comparing the major and minor numbers to the filesystem
passed in on the command line. If there is a match, then the filesystem
is currently mounted and running fsck is dangerous.
Allow stat access to all block devices so that fsck can compare
major/minor values.
Addresses the following denials:
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sde5"
dev="tmpfs" ino=15649 scontext=u:r:fsck:s0
tcontext=u:object_r:metadata_block_device:s0 tclass=blk_file
permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sda25"
dev="tmpfs" ino=15528 scontext=u:r:fsck:s0
tcontext=u:object_r:modem_block_device:s0 tclass=blk_file permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sda31"
dev="tmpfs" ino=15552 scontext=u:r:fsck:s0
tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sdd3"
dev="tmpfs" ino=15600 scontext=u:r:fsck:s0
tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
Bug: 35324014
Bug: 33781554
Test: device boots and no SELinux denials.
Change-Id: I5af4a334ec41952887914eec4eee5c60cc441a66
Motivation:
Provide the ability to phase in new security policies by
applying them to apps with a minimum targetSdkVersion.
Place untrusted apps with targetSdkVersion<=25 into the
untrustd_app_25 domain. Apps with targetSdkVersion>=26 are placed
into the untrusted_app domain. Common rules are included in the
untrusted_app_all attribute. Apps with a more recent targetSdkVersion
are granted fewer permissions.
Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Bug: 35323421
Change-Id: Ie6a015566fac07c44ea06c963c40793fcdc9a083
The rules for the two types were the same and /data/app-ephemeral is
being removed. Remove these types.
Test: Builds
Change-Id: I520c026395551ad1362dd2ced53c601d9e6f9b28
There are many character files that are unreachable to all processes
under selinux policies. Ueventd and init were the only two domains that
had access to these generic character files, but auditing proved there
was no use for that access. In light of this, access is being completely
revoked so that the device nodes can be removed, and a neverallow is
being audited to prevent future regressions.
Test: The device boots
Bug: 33347297
Change-Id: If050693e5e5a65533f3d909382e40f9c6b85f61c
Since it was introduced it caused quite a few issues and it spams the
SElinux logs unnecessary.
The end goal of the audit was to whitelist the access to the
interpreter. However that's unfeasible for now given the complexity.
Test: devices boots and everything works as expected
no more auditallow logs
Bug: 29795519
Bug: 32871170
Change-Id: I9a7a65835e1e1d3f81be635bed2a3acf75a264f6
This neverallow addition addresses the renaming of files in exploits in
order to bypass denied permissions. An example of a similar use case of
using mv to bypass permission denials appeared in a recent project zero
ChromeOS exploit as one of the steps in the exploit chain.
https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html
Additionally, vold and init both had permission sets that allowed them
to rename, but neither of them seem to need it. Therefore the rename
permission has also been removed from these two .te files.
Test: The device boots successfully
Change-Id: I07bbb58f058bf050f269b083e836c2c9a5bbad80
As of https://android-review.googlesource.com/324092, ephemeral_app is
now an appdomain, so places where both appdomain and ephemeral_app are
granted the same set of rules can be deleted.
Test: policy compiles.
Change-Id: Ideee710ea47af7303e5eb3af1331653afa698415
Replace the global debuggerd with a per-process debugging helper that
gets exec'ed by the process that crashed.
Bug: http://b/30705528
Test: crasher/crasher64, `debuggerd <pid>`, `kill -ABRT <pid>`
Change-Id: Iad1b7478f7a4e2690720db4b066417d8b66834ed
Don't allow processes to list out the contents of the directory
/dev/__properties__. This is an implementation specific detail that
shouldn't be visible to processes.
Test: Device boots and no problems reading individual properties.
Test: ls -la /dev/__properties__ fails
Change-Id: I4df6a829b0d22e30fb2c38030c690fc4a356f6a3
6e4508e625 inadvertently removed access
to ro.serialno and ro.boot.serialno from ADB shell. This is needed for
CTS. This commit thus reinstates the access.
Test: adb shell getprop ro.serialno
Bug: 33700679
Change-Id: I62de44b1631c03fcd64ceabaf33bbaeb869c2851
ro.runtime.firstboot system property is only used internally by
system_server to distinguish between first start after boot from
consecutive starts (for example, this happens when full-disk
encryption is enabled). The value of the property is a
millisecond-precise timestamp which can help track individual
device. Thus apps should not have access to this property.
Test: Device boots fine, reading ro.runtime.firstboot from an app results in an error and SELinux denial.
Bug: 33700679
Change-Id: I4c3c26a35c5dd840bced3a3e53d071f45317f63c
This restricts access to ro.serialno and ro.boot.serialno, the two
system properties which contain the device's serial number, to a
select few SELinux domains which need the access. In particular, this
removes access to these properties from Android apps. Apps can access
the serial number via the public android.os.Build API. System
properties are not public API for apps.
The reason for the restriction is that serial number is a globally
unique identifier which cannot be reset by the user. Thus, it can be
used as a super-cookie by apps. Apps need to wean themselves off of
identifiers not resettable by the user.
Test: Set up fresh GMS device, install some apps via Play, update some apps, use Chrome
Test: Access the device via ADB (ADBD exposes serial number)
Test: Enable MTP over USB, use mtp-detect to confirm that serial number is reported in MTP DeviceInfo
Bug: 31402365
Bug: 33700679
Change-Id: I4713133b8d78dbc63d8272503e80cd2ffd63a2a7
Add a compile time assertion that only authorized SELinux domains are
allowed to touch the metadata_block_device. This domain may be wiped at
will, and we want to ensure that we're not inadvertently destroying
other people's data.
Test: policy compiles.
Change-Id: I9854b527c3d83e17f717d6cc8a1c6b50e0e373b6
In order to support platform changes without simultaneous updates from
non-platform components, the platform and non-platform policies must be
split. In order to provide a guarantee that policy written for
non-platform objects continues to provide the same access, all types
exposed to non-platform policy are versioned by converting them and the
policy using them into attributes.
This change performs that split, the subsequent versioning and also
generates a mapping file to glue the different policy components
together.
Test: Device boots and runs.
Bug: 31369363
Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317
Broke the dragon build:
libsepol.report_failure: neverallow on line 304 of system/sepolicy/public/domain.te (or line 8638 of policy.conf) violated by allow kernel device:chr_file { create setattr };
libsepol.check_assertions: 1 neverallow failures occurred
Error while expanding policy
This reverts commit ed0b4eb366.
Change-Id: I5d55ab59ed72ce7c19a10ddbb374f9f3b3fae4fd
By default, files created in /dev are labeled with the "device" label
unless a different label has been assigned. The direct use of this
generic label is discouraged (and in many cases neverallowed) because
rules involving this label tend to be overly broad and permissive.
Today, generically labeled character devices can only be opened, read,
or written to by init and ueventd.
$ sesearch --allow -t device -c chr_file -p open,read,write out/target/product/marlin/root/sepolicy
allow init device:chr_file { setattr read lock getattr write ioctl open append };
allow ueventd device:chr_file { read lock getattr write ioctl open append };
this is enforced by the following SELinux neverallow rule (compile time
assertion + CTS test):
neverallow { domain -init -ueventd } device:chr_file { open read write };
Start auditallowing ueventd access to /dev character device files with the
default SELinux label. This doesn't appear to be used, but let's prove it.
While ueventd is expected to create files in /dev, it has no need to open
most of the files it creates.
Note, however, that because ueventd has mknod + setfscreate permissions,
a malicious or compromised ueventd can always create a device node under
an incorrect label, and gain access that way.
The goal of this change is to prove that no process other than init are
accessing generically labeled files in /dev.
While I'm here, tighten up the compile time assertion for
device:chr_file to include more permissions.
Test: policy compiles + device boots with no granted messages.
Change-Id: Ic98b0ddc631b49b09e58698d9f40738ccedd1fd0
Only init and ueventd have any access to /dev/port, and neither should
have any use for it. As it stands, leaving port in just represents
additional attack surface with no useful functionality, so it should be
removed if possible, not only from Pixel devices, but from all Android
devices.
Test: The phone boots successfully
Bug:33301618
Change-Id: Iedc51590f1ffda02444587d647889ead9bdece3f
urandom_device and random_device have the exact same security
properties. Collapse them into one type.
Test: device boots and /dev/urandom is labeled correctly.
Change-Id: I12da30749291bc5e37d99bc9422bb86cb58cec41
The other domains either don't have the same backwards compatibility
issues (isolated_app) or are privileged components that are pretty much
part of the platform and can be expected to meet a higher standard.
It would be possible to expose a build option for disabling the ART JIT,
allowing conditional removal of execmem from some of these domains too
(ones not ever using the WebView, until that's always in isolated_app).
Bug: 20013628
Change-Id: Ic22513157fc8b958b2a3d60381be0c07b5252fa5
The webview_zygote is a new unprivileged zygote and has its own sockets for
listening to fork requests. However the webview_zygote does not run as root
(though it does require certain capabilities) and only allows dyntransition to
the isolated_app domain.
Test: m
Test: angler boots
Bug: 21643067
Change-Id: I89a72ffe6dcb983c4a44048518efd7efb7ed8e83
The underlying ioctl denial was fixed in device-specific policy.
It's not needed in core policy.
A search of SELinux denials shows no reported denials, other than the
ones showing up on marlin.
This reverts commit ec3285cde0.
(cherrypicked from commit 863ce3e7c7)
Test: AndroiTS GPS Test app shows GPS data, no SELinux denials.
Bug: 32290392
Change-Id: I1ba7bad43a2cdd7cdebbe1c8543a71eee765621d
Filesystem capabilities should only be set by the build tools
or by recovery during an update. Place a neverallow ensuring
this property.
Change-Id: I136c5cc16dff0c0faa3799d0ab5e29b43454a610
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c