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>
rule_map_free() took as a parameter a boolean menu rule_map_switch
that was used to determine if it should free the key pointer that
is also in the table. On GLIBC variants, calls to hdestroy do not
free the key pointer, on NON-GLIBC variants, it does. The original
patch was meant to correct this, however, it always passes "destroy"
as the rule_map_switch. On GLIBC variants this is fine, however on
NON-GLIBC variants, that free was compiled out, and the free() was
handled by hdestroy. In cases of failure where the rule_map was not
in the htable, those key's were not properly free'd.
Change-Id: Ifdf616e09862bca642a4d31bf0cb266168170e50
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Despite removing these from AOSP policy they seem to still be
present in device policies. Prohibit them via neverallow.
We would also like to minimize execmem to only app domains
and others using ART, but that will first require eliminating it
from device-specific service domains (which may only have it
due to prior incorrect handling of text relocations).
Change-Id: Id1f49566779d9877835497d8ec7537abafadadc4
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow vold, healthd, slideshow, and watchdogd access to /dev/kmsg.
These processes log to the kernel dmesg ring buffer, so they need
write access to that file.
Addresses the following denials:
avc: denied { write } for pid=134 comm="watchdogd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:watchdogd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=166 comm="healthd" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:healthd:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
avc: denied { write } for pid=180 comm="vold" name="kmsg" dev="tmpfs" ino=9248 scontext=u:r:vold:s0 tcontext=u:object_r:kmsg_device:s0 tclass=chr_file permissive=0
These denials were triggered by the change in
https://android-review.googlesource.com/151209 . Prior to that change,
any code which called klog_init would (unnecessarily) create the
device node themselves, rather than using the already existing device
node.
Drop special /dev/__null__ handling from watchdogd. As of
https://android-review.googlesource.com/148288 , watchdogd no longer
creates it's own /dev/null device, so it's unnecessary for us
to allow for it.
Drop mknod from healthd, slideshow, and watchdogd. healthd and slideshow
only needed mknod to create /dev/__kmsg__, which is now obsolete.
watchdogd only needed mknod to create /dev/__kmsg__ and /dev/__null__,
which again is now obsolete.
(cherry picked from e2651972c1)
Bug: 21242418
Change-Id: If01c8001084575e7441253f0fa8b4179ae33f534
