Ideally, public should only contain APIs (types / attributes) for
vendor. The other statements like allow/neverallow/typeattributes are
regarded as implementation detail for platform and should be in private.
Bug: 232023812
Test: m selinux_policy
Test: diff <(git diff --staged | grep "^-" | cut -b2- | sort) \
<(git diff --staged | grep "^+" | cut -b2- | sort)
Test: remove comments on plat_sepolicy.cil, replace base_typeattr_*
to base_typeattr and then compare old and new plat_sepolicy.cil
Change-Id: I5e7d2da4465ab0216de6bacdf03077d37f6ffe12
/tmp is a volatile temporary storage location for the shell user.
As with /data/local/tmp, it is owned by shell:shell and is chmod 771.
Bug: 311263616
Change-Id: Ice0229d937989b097971d9db434d5589ac2da99a
Overlayfs failed to mount during second stage init because init is
lacking these permissions.
These permissions are asserted by the overlayfs driver during mount
operation, see fs/overlayfs/super.c:ovl_check_rename_whiteout
(https://source.corp.google.com/kernel-upstream/fs/overlayfs/super.c;l=1182;bpv=1;bpt=1)
Bug: 243501054
Test: adb remount && check that overlay is active after reboot
Change-Id: I258646b65a49487e6f22a6742ff59e9a0d57b5c0
As a reminder, per:
https://source.corp.google.com/search?q=p:aosp-master%20file:sepolicy%20-file:prebuilts%20proc_bpf%20file:genfs
we currently have:
aosp-master system/sepolicy/private/genfs_contexts
genfscon proc /sys/kernel/bpf_ u:object_r:proc_bpf:s0
genfscon proc /sys/kernel/unprivileged_bpf_ u:object_r:proc_bpf:s0
genfscon proc /sys/net/core/bpf_ u:object_r:proc_bpf:s0
So the above are the files which will no longer be writable by init.
A cs/ search for p:android$ (/sys/kernel/bpf_|/sys/kernel/unprivileged_bpf_|/sys/net/core/bpf_) file:[.]rc
only finds bpfloader.rc init script as actually doing these writes.
Those writes are removed in:
https://android-review.git.corp.google.com/c/platform/system/bpf/+/2325617
'bpfloader - move sysctl setting from rc to binary'
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I19ccdf293966dd982e1d36836b0b962d99ed7275
There should be no need for this and it fixes a long outstanding TODO.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id1764cbc713addbbda6827fe6c6689e45e8f584c
Remove references in sepolicy. Leave a few of the types defined since
they're public and may be used in device-specific policy.
Bug: 211461392
Test: build/boot cuttlefish
Change-Id: I615137b92b82b744628ab9b7959ae5ff28001169
As a follow-up to https://r.android.com/2078213, remove init's write
access to directories with type system_userdir_file or
media_userdir_file. This has been made possible by moving the creation
of /data/user/0 and /data/media/obb to vold.
Bug: 156305599
Change-Id: Ib9f43f2b111518833efe08e8cacd727c75b80266
init should use subcontext (vendor_init) for actions/services from
/{vendor, odm} partitions. However, when configs are from vendor APEXes,
init can't tell whether the APEXes are from /{vendor, odm} just by
looking at the config file paths.
Instead, init can look up /apex/apex-info-list.xml for APEXes
preinstalled paths to tell APEXes' original partition.
Bug: 232021354
Test: atest CtsBluetoothTestCases
(Cuttlefish has BT HAL APEX in /vendor)
Change-Id: I8cb5d9eb3970790499ef1eb1ee00851591a42e98
Creating a per-user encrypted directory such as /data/system_ce/0 and
the subdirectories in it too early has been a recurring bug. Typically,
individual services in system_server are to blame; system_server has
permission to create these directories, and it's easy to write
"mkdirs()" instead of "mkdir()". Such bugs are very bad, as they
prevent these directories from being encrypted, as encryption policies
can only be set on empty directories. Due to recent changes, a factory
reset is now forced in such cases, which helps detect these bugs;
however, it would be much better to prevent them in the first place.
This CL locks down the ability to create these directories to just vold
and init, or to just vold when possible. This is done by assigning new
types to the directories that contain these directories, and then only
allowing the needed domains to write to these parent directories. This
is similar to what https://r.android.com/1117297 did for /data itself.
Three new types are used instead of just one, since these directories
had three different types already (system_data_file, media_rw_data_file,
vendor_data_file), and this allows the policy to be a bit more precise.
A significant limitation is that /data/user/0 is currently being created
by init during early boot. Therefore, this CL doesn't help much for
/data/user/0, though it helps a lot for the other directories. As the
next step, I'll try to eliminate the /data/user/0 quirk. Anyway, this
CL is needed regardless of whether we're able to do that.
Test: Booted cuttlefish. Ran 'sm partition disk:253,32 private', then
created and deleted a user. Used 'ls -lZ' to check the relevant
SELinux labels on both internal and adoptable storage. Also did
similar tests on raven, with the addition of going through the
setup wizard and using an app that creates media files. No
relevant SELinux denials seen during any of this.
Bug: 156305599
Change-Id: I1fbdd180f56dd2fe4703763936f5850cef8ab0ba
Now that FDE (Full Disk Encryption) is no longer supported, the SELinux
policy doesn't need to support it. Remove two rules that are no longer
needed. Also update some comments that implied that other rules were
needed only because of FDE support, when actually they are still needed
for other reasons. Finally, fix some outdated documentation links.
Bug: 208476087
Change-Id: I4e03dead91d34fcefdfcdc68d44dd97f433d6eaf
Init will try restorecon /dev/console, together with /dev, at the second
stage boot.
Bug: 193118220
Test: atest MicrodroidHostTestCases
Change-Id: Ie9796368b54bb0773eabf5ff6feb2b4aa41d0bfa
The root init.rc does "write /proc/cpu/alignment 4", but we don't
actually allow this write in core sepolicy. This seems to be a 32-bit
ARM only proc file.
Noticed when booting 32-bit ARM Cuttlefish.
Bug: 145371497
Change-Id: Ic099395708f7236bcc2fc5c561809a7e129786de
Any FUSE filesystem will receive the 'fuse' type when mounted. It is
possible to change this behaviour by specifying the "context=" or
"fscontext=" option in mount().
Because 'fuse' has historically been used only for the emulated storage,
it also received the 'sdcard_type' attribute. Replace the 'sdcard_type'
attribute from 'fuse' with the new 'fusefs_type'. This attribute can be
attached on derived types (such as app_fusefs).
This change:
- Remove the neverallow restriction on this new type. This means any
custom FUSE implementation can be mounted/unmounted (if the correct
allow rule is added). See domain.te.
- Change the attribute of 'fuse' from 'sdcard_type' to 'fusefs_type'.
See file.te.
- Modify all references to 'sdcard_type' to explicitly include 'fuse'
for compatibility reason.
Bug: 177481425
Bug: 190804537
Test: Build and boot aosp_cf_x86_64_phone-userdebug
Change-Id: Id4e410a049f72647accd4c3cf43eaa55e94c318f
This reverts commit e95e0ec0a5.
Now that b/186727553 is fixed, it should be safe to revert this revert.
Test: build
Bug: 184381659
Change-Id: Ibea3882296db880f5cafe4f9efa36d79a183c8a1
* changes:
Revert "Add a neverallow for debugfs mounting"
Revert "Add neverallows for debugfs access"
Revert "Exclude vendor_modprobe from debugfs neverallow restrictions"
Revert "Check that tracefs files are labelled as tracefs_type"
Revert submission 1668411
Reason for revert: Suspect for b/186173384
Reverted Changes:
Iaa4fce9f0:Check that tracefs files are labelled as tracefs_t...
I743a81489:Exclude vendor_modprobe from debugfs neverallow re...
I63a22402c:Add neverallows for debugfs access
I289f2d256:Add a neverallow for debugfs mounting
Change-Id: Ie04d7a4265ace43ba21a108af85f82ec137c6af0
Revert submission 1668411
Reason for revert: Suspect for b/186173384
Reverted Changes:
Iaa4fce9f0:Check that tracefs files are labelled as tracefs_t...
I743a81489:Exclude vendor_modprobe from debugfs neverallow re...
I63a22402c:Add neverallows for debugfs access
I289f2d256:Add a neverallow for debugfs mounting
Change-Id: I9b7d43ac7e2ead2d175b265e97c749570c95e075
Android R launching devices and newer must not ship with debugfs
mounted. For Android S launching devices and newer, debugfs must only be
mounted in userdebug/eng builds by init(for boot time initializations)
and dumpstate(for grabbing debug information from debugfs using the
dumpstate HAL).
This patch adds neverallow statements to prevent othe processes
being provided access to debugfs when the flag PRODUCT_SET_DEBUGFS_RESTRICTIONS
is set to true.
Test: make with/without PRODUCT_SET_DEBUGFS_RESTRICTIONS
Bug: 184381659
Change-Id: I63a22402cf6b1f57af7ace50000acff3f06a49be
Android R launching devices and newer must not ship with debugfs
mounted. For Android S launching devices and newer, debugfs must only be
mounted in userdebug/eng builds by init(for boot time initializations)
and dumpstate(for grabbing debug information from debugfs). This patch
adds a neverallow statement that prevents processes other than init
from being provided access to mount debugfs in non-user builds
when the flag PRODUCT_SET_DEBUGFS_RESTRICTIONS is set to true.
Test: make with/without PRODUCT_SET_DEBUGFS_RESTRICTIONS
Bug: 184381659
Change-Id: I289f2d25662a78678929e29f83cb31cebd8ca737
Vendor boot hal, init, and vold processes all require permission.
Test: build and boot aosp_cf_x86_64_phone
Bug: 173815685
Change-Id: I15692dcd39dfc9c3a3b7d8c12d03eff0a7c96f72
Bug: 168907513
Test: verified the correct working of the v2 uid/pid hierarchy in normal
and recovery modes
This reverts commit aa8bb3a29b.
Change-Id: Ib344d500ea49b86e862e223ab58a16601eebef47
a54bed6907
Bug: 151660495
Test: verified proper boot in regular mode and proper working of adb in
recovery
Change-Id: Id70d27a6162af6ede94661005d80a2a780057089
This change will help debug builds with keeping debugfs
disabled during run time. Instead, debugfs will be mounted by init
to enable boot time initializations to set up debug data collection
and unmounted after boot. It will be also be mounted by dumpstate
for bug report generation and unmounted after.
It resolves the following avc denial:
avc: denied { mounton } for comm="init" path="/sys/kernel/debug" dev="debugfs"
ino=1 scontext=u:r:init:s0 tcontext=u:object_r:debugfs:s0 tclass=dir permissive=0
Bug: 176936478
Test: make && boot
Change-Id: I5bc819eb0cc36bdc32565c17a16da8838baf946a
The initial launch of snapuserd happens in first-stage init, before
sepolicy is loaded, since snapuserd is needed to mount initial
partitions. After sepolicy is loaded, we immediately re-launch snapuserd
in the correct context. This requires a transition similar to init.
The "allow" lines for the kernel happen in permissive mode, since we
need to relabel critical parts of /dev/block in order to re-launch
snapuserd.
Bug: 173476209
Test: OTA applies with ro.virtual_ab.compression.enabled = true
Change-Id: I80184e737ccb558107a14b384a61f7fec31c9428
the cgroups v2 uid/gid hierarchy will replace cgroup for all sepolicy
rules. For this reason, old rules have to be duplicated to cgroup_v2,
plus some rules must be added to allow the ownership change for cgroup
files created by init and zygote.
Test: booted device, verified correct access from init, system_server
and zygote to the uid/pid cgroup files
Change-Id: I80c2a069b0fb409b442e1160148ddc48e31d6809
Define access rights to new per-API level task profiles and cgroup
description files under /etc/task_profiles/.
Bug: 172066799
Test: boot with per-API task profiles
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I04c9929fdffe33a9fc82d431a53f47630f9dcfc3
Restrict access to controlling snapuserd via ctl properties. Allow
update_engine to control snapuserd, and connect/write to its socket.
update_engine needs this access so it can create the appropriate dm-user
device (which sends queries to snapuserd), which is then used to build
the update snapshot.
This also fixes a bug where /dev/dm-user was not properly labelled. As a
result, snapuserd and update_engine have been granted r_dir_perms to
dm_user_device.
Bug: 168554689
Test: full ota with VABC enabled
Change-Id: I1f65ba9f16a83fe3e8ed41a594421939a256aec0