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
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
These ioctls don't need to be allowed, as they'd only be needed to set
project quota IDs. But this is only done by other domains (installd,
vold, and mediaprovider_app). Probably it was originally planned for an
init script to run 'chattr -p ID', but this didn't end up happening.
This is a basically revert of commit 4de3228c46 ("Allow toolbox to set
project quota IDs.") (https://r.android.com/1224007).
Also remove an outdated comment at the top of the file.
Test: booted Cuttlefish, no denials seen.
Change-Id: If61179a35f419c6cbfcf1432a86b2c1375db71ed
These ioctls are required to set a default project quota ID on
/data/media.
Bug: 146419093
Test: verified chattr call from rootdir/init.rc
Change-Id: I0c9028e0a6502302fe81a73dfa087261a36d9863
This allows init to call chattr to allow casefolding on /data/media
Test: lsattr on /data/media on device with casefolding support
Bug: 138322712
Change-Id: I5715484d872088517f67c62a78344a2d417dd77f
system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.
Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.
Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
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
