Allow device builders to pass arbitrary m4 definitions
during the build via make variable BOARD_SEPOLICY_M4DEFS.
This enables OEMs to define their own static policy build
conditionals.
Change-Id: Ibea1dbb7b8615576c5668e47f16ed0eedfa0b73c
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Init never uses / add service manager services. It doesn't make
sense to allow these rules to init. Adding a rule of this type
is typically caused by a process inappropriately running in init's
SELinux domain, and the warning message:
Warning! Service %s needs a SELinux domain defined; please fix!
is ignored.
In addition, add neverallow rules to domain.te which prevent
nonsense SELinux service_manager rules from being added.
Change-Id: Id04a50d1826fe451a9ed216aa7ab249d0393cc57
Domains have the ability to read normal tmpfs files but not symlinks.
Grant this ability. In particular, allow domains to read /mnt/sdcard.
Addresses the following denial:
type=1400 audit(0.0:19):avc: denied { read } for comm=4173796E635461736B202333 name="sdcard" dev="tmpfs" ino=7475 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:tmpfs:s0 tclass=lnk_file permissive=0
(cherry-pick of commit: 2b0b8299b2)
Bug: 20755029
Change-Id: Iaa5dc278b34faf33473d3e49f92d8766ae5563c0
Domains have the ability to read normal tmpfs files but not symlinks.
Grant this ability. In particular, allow domains to read /mnt/sdcard.
Addresses the following denial:
type=1400 audit(0.0:19):avc: denied { read } for comm=4173796E635461736B202333 name="sdcard" dev="tmpfs" ino=7475 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:tmpfs:s0 tclass=lnk_file permissive=0
Bug: 20755029
Change-Id: I0268eb00e0eb43feb2d5bca1723b87b7a44f31a9
/proc/iomem is currently given the proc label but contains system information
which should not be available to all processes.
Bug: 22008387
Change-Id: I4f1821f40113a743ad986d13d8d130ed8b8abf2f
Lowercase local variables and clear them to be
consistent with other recipes and prevent polluting
Make's global name space with set variables.
Change-Id: If455cd4f33d5babbea985867a711e8a10c21a00f
Signed-off-by: William Roberts <william.c.roberts@intel.com>
To help reduce code injection paths, a neverallow is placed
to prevent domain, sans untrusted_app and shell, execute
on data_file_type. A few data_file_type's are also exempt
from this rule as they label files that should be executable.
Additional constraints, on top of the above, are placed on domains
system_server and zygote. They can only execute data_file_type's
of type dalvikcache_data_file.
Change-Id: I15dafbce80ba2c85a03c23128eae4725703d5f02
Signed-off-by: William Roberts <william.c.roberts@intel.com>
For example, when launching into an isolated process, we need to drop
all mounts inherited from the root namespace.
avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:fuse:s0 tclass=filesystem permissive=1
Bug: 22192518
Change-Id: Iafbea2c365c1080bdf20d7fa066c304901e582ba
Produce a list of neverallow assertions from seapp_contexts into
a separate file, general_seapp_context_neverallows, to be used
during CTS neverallow checking.
Change-Id: I171ed43cf4ae4961f66d5d8f56695345493f1261
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
avc: denied { sys_chroot } for capability=18 scontext=u:r:vold:s0 tcontext=u:r:vold:s0 tclass=capability permissive=1
avc: denied { mounton } for path="/storage" dev="tmpfs" ino=4155 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir permissive=1
avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=filesystem permissive=0
Bug: 21858077
Change-Id: Ie481d190c5e7a774fbf80fee6e39a980f382967e
Introduce "neverallow" rules for seapp_contexts. A neverallow rule is
similar to the existing key-value-pair entries but the line begins
with "neverallow". A neverallow violation is detected when all keys,
both inputs and outputs are matched. The neverallow rules value
parameter (not the key) can contain regular expressions to assist in
matching. Neverallow rules are never output to the generated
seapp_contexts file.
Also, unless -o is specified, checkseapp runs in silent mode and
outputs nothing. Specifying - as an argument to -o outputs to stdout.
Sample Output:
Error: Rule in File "external/sepolicy/seapp_contexts" on line 87: "user=fake domain=system_app type=app_data_file" violates neverallow in File "external/sepolicy/seapp_contexts" on line 57: "user=((?!system).)* domain=system_app"
Change-Id: Ia4dcbf02feb774f2e201bb0c5d4ce385274d8b8d
Signed-off-by: William Roberts <william.c.roberts@intel.com>
