To support linker-specific property, sys.linker.* has been defined as
linker_prop. This will have get_prop access from domain so all binaries
can start with linker using proper property access level.
Bug: 138920271
Test: m -j && Confirmed from cuttlefish that get_prop errors are no longer found
Change-Id: Iaf584e0cbdd5bca3d5667e93cf9a6401e757a314
Additional permission is required for linkerconfig from domain to get
access to ld.config.txt file from linker. This change allows linker to
get /dev/linkerconfig/ld.config.txt
Bug: 138920271
Test: m -j && confirmed from cuttlefish
Change-Id: Id130a072add8ae82840b0b4d9e997e146f502124
Sepolicy for linkerconfig generator and ld.config.txt file from
generator
Bug: 135004088
Test: m -j & tested from device
Change-Id: I2ea7653a33996dde67a84a2e7a0efa660886434a
This reverts commit e47d2365a8.
Reason for revert: Original CL was not the cause of the breakage. It went green before this revert landed. https://android-build.googleplex.com/builds/branches/aosp-master/grid?
Original CL went in 5695273.
Went green in 5695399.
Revert went in 5695588.
Change-Id: Ie4d7065fe7d3c58cdff99c2b7d76b50b941895bb
This reverts commit 0c0ba46192.
Reason for revert: <Broken build 5695273 on aosp-master on aosp_x86_64-eng>
Change-Id: I763f19aa5b72f2e1aaebbc78bb8ab3020c3d2a7b
In order to show licensing information, we need to read it from
an asset stored in the .apex file.
Bug: 135183006
Test: Manual; settings can access apex files stored on /data
Change-Id: I71fbde6e295d9c890c9b9b0449e5150834a6680e
To install GSIs on external storage (such as sdcards), gsid needs some
additional privileges:
- proc_cmdline and device-tree access to call ReadDefaultFstab().
This is ultimately used to check whether system's dm-verity has
check_at_most_once enabled, which is disallowed with sdcards.
- vfat read/write access to write files to the sdcard. Note that
adopted sdcards are not supported here.
- read access to the sdcard block device. To enable this without
providing access to vold_block_device, a new sdcard_block_device
label was added. Devices must apply this label appropriately to
enable gsid access.
- FIBMAP access for VFAT filesystems, as they do not support FIEMAP.
This only appears to work by granting SYS_RAWIO.
Bug: 126230649
Test: adb shell su root gsi_tool install --install_dir=/mnt/media_rw/...
works without setenforce 0
Change-Id: I88d8d83e5f61d4c0490f912f226fe1fe38cd60ab
fsverity_init is a new shell script that uses mini-keyctl for the actual
key loading. Given the plan to implement keyctl in toybox, we label
mini-keyctl as u:object_r:toolbox_exec:s0.
This gives us two benefits:
- Better compatibility to keyctl(1), which doesn't have "dadd"
- Pave the way to specify key's security labels, since keyctl(1)
doesn't support, and we want to avoid adding incompatible option.
Test: Boot without SELinux denial
Test: After boot, see the key in /product loaded
Bug: 128607724
Change-Id: Iebd7c9b3c7aa99ad56f74f557700fd85ec58e9d0
This is needed because some oat dex files are generated without world
readable permissions. See the bug for details.
We are still constrained by the SELinux rules above.
Bug: 129048073
Change-Id: I84e34f83ceb299ff16b29a78f16c620fc0aa5d68
Move complete domain to private/. Move referencing parts in domain
and kernel to private.
Bug: 128840749
Test: m
Change-Id: I5572c3b04e41141c8f4db62b1361e2b392a5e2da
Allow everyone to look for keys in the fsverity keyring. This is
required to access fsverity-protected files, at all.
This set of permissions is analogous to allowances for the fscrypt
keyring and keys.
Bug: 125474642
Test: m
Test: manual
Change-Id: I6e8c13272cdd76d9940d950e9dabecdb210691b1
Add ART boot integrity check domain. Give it rights to run
fsverity and delete boot classpath artifacts.
Bug 125474642
Test: m
Test: boot
Change-Id: I933add9b1895ed85c43ec712ced6ffe8f820c7ec
Vendors should be able to specify additional cgroups and task profiles
without changing system files. Add access rules for /vendor/etc/cgroups.json
and /vendor/etc/task_profiles.json files which will augment cgroups and
task profiles specified in /etc/cgroups.json and /etc/task_profiles.json
system files. As with system files /vendor/etc/cgroups.json is readable
only by init process. task_profiles.json is readable by any process that
uses cgroups.
Bug: 124960615
Change-Id: I12fcff0159b4e7935ce15cc19ae36230da0524fc
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Add art_apex_postinstall domain that is allowed to move
precreated AoT artifacts from /data/ota.
Bug: 125474642
Test: m
Change-Id: Id674e202737155a4ee31187f096d1dd655001fdd
In preparation for moving other components to private, so that
private-only components can stay private.
Bug: 125474642
Test: m
Change-Id: Iff1ecabc4f45051d06e062b3338a117c09b39ff9
In order to support deleting session files after a staged session reaches
a final state, installd will need to delete the session directories from
/data/staging.
Bug: 123624108
Test: triggered 2 flows in which a staged session reaches a final state
and made sure installd can delete the session files
Change-Id: I76a7d4252d1e033791f67f268cf941672c5e6a3a
In preparation for additions that should be private-only, move
the neverallows to domain's private part.
Bug: 125474642
Test: m
Change-Id: I7def500221701500956fc0b6948afc58aba5234e
Will be used to forcefully turn on memfd if device supports it.
Currently used only for debugging.
Change-Id: I46a1b7169677ea552d4b092e7501da587c42ba1a
Signed-off-by: Joel Fernandes <joelaf@google.com>
In order to support rollback for apex files, apexd will need to unlink
previously active apex files in /data/apex/active folder. Those files
are hardlinked from /data/staging/session_XXXX which means that they
have staging_data_file:file SELinux fields.
I double checked that this change won't allow apexd to unlink files in
/data/staging/session_XXXX folders, because it will lack write access,
logcat contains following entries:
avc: denied { write } for name="session_305119585" dev="sda13" ino=5496838 scontext=u:r:apexd:s0 tcontext=u:object_r:staging_data_file:s0 tclass=dir permissive=0
Bug: 122339211
Test: verified that apexd can't unlink files in /data/staging/session_XXXX
Change-Id: Iddef724c3d73269c97d9fa12a05a276fad189ea9
cgroups.json file contains cgroup information required to mount
cgroup controllers and is readable only by init process.
cgroup.rc contains cgroup map information consisting of the list of
cgroups available in the system and their mounting locations. It is
created by init process and should be readable by any processes that
uses cgroups and should be writable only by init process.
task_profiles.json file contains task profiles used to operate on
cgroups. This information should be readable by any process that uses
cgroups and should be writable only by init process.
Bug: 111307099
Test: builds, boots
Change-Id: Ib2c87c0fc3663c7fc69628f05c846519b65948b5
Merged-In: Ib2c87c0fc3663c7fc69628f05c846519b65948b5
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This patch extends the current debug-specific rules to cover user
builds. As a reminder, on user, the target process fork-execs a private
heapprofd process, which then performs stack unwinding & talking to the
central tracing daemon while staying in the target's domain. The central
heapprofd daemon is only responsible for identifying targets & sending
the activation signal. On the other hand, on debug, the central
heapprofd can handle all processes directly, so the necessary SELinux
capabilities depend on the build type.
These rules are necessary but not sufficient for profiling. For zygote
children, the libc triggering logic will also check for the app to
either be debuggable, or go/profileable.
For more context, see go/heapprofd-security & go/heapprofd-design.
Note that I've had to split this into two separate macros, as
exec_no_trans - which is necessary on user, but nice-to-have on debug -
conflicts with a lot of neverallows (e.g. HALs and system_server) for
the wider whitelisting that we do on debug builds.
Test: built & flashed on {blueline-userdebug, blueline-user}, activated profiling of whitelisted/not domains & checked for lack of denials in logcat.
Bug: 120409382
Change-Id: Id0defc3105b99f777bcee2046d9894a2b39c6a29
The application zygote is a new sort of zygote process that is a
child of the regular zygote. Each application zygote is tied to the
application for which it's launched. Once it's started, it will
pre-load some of the code for that specific application, much like
the regular zygote does for framework code.
Once the application zygote is up and running, it can spawn
isolated service processes that run in the isolated_app domain. These
services can then benefit from already having the relevant
application code and data pre-loaded.
The policy is largely the same as the webview_zygote domain,
however there are a few crucial points where the policy is different.
1) The app_zygote runs under the UID of the application that spawned
it.
2) During app_zygote launch, it will call a callback that is
controlled by the application, that allows the application to
pre-load code and data that it thinks is relevant.
Especially point 2 is imporant: it means that untrusted code can run
in the app_zygote context. This context is severely limited, and the
main concern is around the setgid/setuid capabilities. Those conerns
are mitigated by installing a seccomp filter that only allows
setgid/setuid to be called in a safe range.
Bug: 111434506
Test: app_zygote can start and fork children without denials.
Change-Id: I1cc49ee0042d41e5ac6eb81d8f8a10ba448d4832
We will generate precompiled layouts as part of the package install or upgrade
process. This means installd needs to be able to invoke viewcompiler. This
change gives installd and viewcompiler the minimal set of permissions needed for
this to work.
Bug: 111895153
Test: manual
Change-Id: Ic1fe60bd264c497b5f79d9e1d77c2da4e092377b
These are APEX files in /data/staging, and will be accessed by the loop
driver in the kernel.
Bug: 118865310
Test: no denials on emulator
Change-Id: I5c849b6677566cb00d28011352b9dc6b787a0bc4
Test: basic workflow between apexd and PackageManager tested with
changes being developed.
Bug: 118865310
Change-Id: I1ae866f33e9b22493585e108c4fd45400493c7ac
When an app uses renderscript to compile a Script instance,
renderscript compiles and links the script using /system/bin/bcc and
/system/bin/ld.mc, then places the resulting shared library into the
application's code_cache directory. The application then dlopen()s the
resulting shared library.
Currently, this executable code is writable to the application. This
violates the W^X property (https://en.wikipedia.org/wiki/W%5EX), which
requires any executable code be immutable.
This change introduces a new label "rs_data_file". Files created by
/system/bin/bcc and /system/bin/ld.mc in the application's home
directory assume this label. This allows us to differentiate in
security policy between app created files, and files created by
renderscript on behalf of the application.
Apps are allowed to delete these files, but cannot create or write these
files. This is enforced through a neverallow compile time assertion.
Several exceptions are added to Treble neverallow assertions to support
this functionality. However, because renderscript was previously invoked
from an application context, this is not a Treble separation regression.
This change is needed to support blocking dlopen() for non-renderscript
/data/data files, which will be submitted in a followup change.
Bug: 112357170
Test: cts-tradefed run cts -m CtsRenderscriptTestCases
Change-Id: Ie38bbd94d26db8a418c2a049c24500a5463698a3
Move rules / neverallow assertions from public to private policy. This
change, by itself, is a no-op, but will make future patches easier to
read. The only downside of this change is that it will make git blame
less effective.
Motivation: When rules are placed into the public directory, they cannot
reference a private type. A future change will modify these rules to
reference a private type.
Test: compiles
Bug: 112357170
Change-Id: I56003409b3a23370ddab31ec01d69ff45c80d7e5
This is world-readable so it can be checked in libc's process init.
Test: m
Test: flash sailfish
Bug: 117821125
Change-Id: Iac7317ceb75b5ad9cfb9adabdf16929263fa8a9d
Remove the special case that allowed init to relabel app_data_file and
privapp_data_file. The auditallow added in
ab82125fc8 has never triggered.
Bug: 80190017
Test: policy compiles
Test: no SELinux denials collected for the auditallow rule
Change-Id: Ide7c31e1a0628464ec2fcf041e8975087c39166d
We lose git history with this, but imo the rules being moved don't have
much reference material. Also, as we write more neverallow rules for
CKI, I'd like to consolidate them in private/coredomain.te
Test: m selinux_policy
Change-Id: I6d0c3d2af0c4dfe7dd3cb1d8836b4b5e00db37a4
Create a transient SELinux domain where system_server can perform
certain JIT setup. The idea is that system_server will start in the
system_server_startup domain, setup certain JIT pages, then perform a
one-way transition into the system_server domain. From that point,
further JITing operations are disallowed.
Bug: 62356545
Test: device boots, no permission errors
Change-Id: Ic55b2cc5aba420ebcf62736622e08881a4779004
Assert that only apps and installd may open private app files.
Remove "open" permission for mediaserver/vold and remove their
neverallow exemption.
Test: verify no related audit messages in the logs.
Test: build
Fixes: 80300620
Fixes: 80418809
Bug: 80190017
Change-Id: If0c1862a273af1fedd8898f334c9b0aa6b9be728
When /system/bin/crash_dump is executed from the su domain, do not
perform a domain transition. This allows processes run from that domain
to crash normally without SELinux interfering.
Bug: 114136122
Test: cferris: "This change works for me. I ran the crasher executable on
/data, /data/nativetest, /data/nativetest64 (and even /data/local/tmp).
All of them show that crash_dump can read the executables."
Change-Id: Ic135d61b11774acff37ebfb35831497cddbefdef
llkd needs the ptrace capabilities and dac override to monitor for
live lock conditions on the stack dumps.
Test: compile
Bug: 33808187
Change-Id: Ibc1e4cc10395fa9685c4ef0ca214daf212a5e126
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.
This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:
-user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
+user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
For now, this newly introduced label has no usage, so this change
is essentially a no-op.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
In particular, add assertions limiting which processes may
directly open files owned by apps. Reduce this to just apps, init,
and installd. App data is protected by a combination of selinux
permissions and Unix permissions, so limiting the open permission to
just apps (which are not allowed to have CAP_DAC_OVERRIDE or
CAP_DAC_READ_SEARCH) ensures that only installd and init have
complete access an app's private directory.
In addition to apps/init/installd, other processes currently granted
open are mediaserver, uncrypt, and vold. Uncrypt's access appears to
be deprecated (b/80299612). Uncrypt now uses /data/ota_package
instead. b/80418809 and b/80300620 track removal for vold and
mediaserver.
Test: build/boot aosp_taimen-userdebug. Verify no "granted" audit
messages in the logs.
Bug: 80190017
Bug: 80300620
Bug: 80418809
Fixes: 80299612
Change-Id: I153bc7b62294b36ccd596254a5976dd887fed046
Create a new label for /data/system/dropbox, and neverallow direct
access to anything other than init and system_server.
While all apps may write to the dropbox service, only apps with
android.permission.READ_LOGS, a signature|privileged|development
permission, may read them. Grant access to priv_app, system_app,
and platform_app, and neverallow access to all untrusted_apps.
Bug: 31681871
Test: atest CtsStatsdHostTestCases
Test: atest DropBoxTest
Test: atest ErrorsTests
Change-Id: Ice302b74b13c4d66e07b069c1cdac55954d9f5df
