Programs routinely scan through /system, looking at the files there.
Don't generate an SELinux denial when it happens.
Bug: 21120228
Change-Id: I85367406e7ffbb3e24ddab6f97448704df990603
Only a few system level components should be creating and writing
these files, force a type transition for shared files.
Change-Id: Ieb8aa8a36859c9873ac8063bc5999e9468ca7533
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
Addresses the following error when running CTS on master:
junit.framework.AssertionFailedError: The following errors were encountered when validating the SELinuxneverallow rule:
neverallow { appdomain -bluetooth } self:capability *;
/tmp/SELinuxHostTest5593810182495331783.tmp: error while loading shared libraries: libc++.so: cannot open shared object file: No such file or directory
Also indicate that none of the sepolicy tools need c++ std lib.
(cherry-pick of 0cdb0517be696c0dc6882d289eedd45bf2da918c now made possible by
addition of commit: 28b72eddd54cb1287dd7daae853e8e4b78fa17eb)
Bug: 19617220
Change-Id: I2c5b7ab1ddeb0e02cbaad2b7d5430a0974524a89
Files on the /oem partition are weird. The /oem partition is an ext4
partition, built in the Android tree using the "oem_image" build target
added in build/ commit b8888432f0bc0706d5e00e971dde3ac2e986f2af. Since
it's an ext4 image, it requires SELinux labels to be defined at build
time. However, the partition is mounted using context=u:object_r:oemfs:s0,
which ignores the labels on the filesystem.
Assign all the files on the /oem image to be oemfs, which is consistent
with how they'll be mounted when /oem is mounted.
Other options would be to use an "unlabeled" label, or try to fix the
build system to not require SELinux labels for /oem images.
(cherrypicked from commit 2025fd1476)
Bug: 20816563
Change-Id: Ibe8d9ff626eace8a2d5d02c3f06290105baa59fe
A common source of mistakes when authoring sepolicy is properly
setting up property sets. This is a 3 part step of:
1. Allowing the unix domain connection to the init/property service
2. Allowing write on the property_socket file
3. Allowing the set on class property_service
The macro unix_socket_connect() handled 1 and 2, but could be
confusing for first time policy authors. 3 had to be explicitly
added.
To correct this, we introduce a new macros:
set_prop(sourcedomain, targetprop)
This macro handles steps 1, 2 and 3.
No difference in sediff is expected.
(cherrypicked from commit 625a3526f1)
Change-Id: I630ba0178439c935d08062892990d43a3cc1239e
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
A common source of mistakes when authoring sepolicy is properly
setting up property sets. This is a 3 part step of:
1. Allowing the unix domain connection to the init/property service
2. Allowing write on the property_socket file
3. Allowing the set on class property_service
The macro unix_socket_connect() handled 1 and 2, but could be
confusing for first time policy authors. 3 had to be explicitly
added.
To correct this, we introduce a new macros:
set_prop(sourcedomain, targetprop)
This macro handles steps 1, 2 and 3.
No difference in sediff is expected.
Change-Id: I630ba0178439c935d08062892990d43a3cc1239e
Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
Files on the /oem partition are weird. The /oem partition is an ext4
partition, built in the Android tree using the "oem_image" build target
added in build/ commit b8888432f0bc0706d5e00e971dde3ac2e986f2af. Since
it's an ext4 image, it requires SELinux labels to be defined at build
time. However, the partition is mounted using context=u:object_r:oemfs:s0,
which ignores the labels on the filesystem.
Assign all the files on the /oem image to be oemfs, which is consistent
with how they'll be mounted when /oem is mounted.
Other options would be to use an "unlabeled" label, or try to fix the
build system to not require SELinux labels for /oem images.
Bug: 20816563
Change-Id: Ibe8d9ff626eace8a2d5d02c3f06290105baa59fe
MAC address access is no longer allowed via the java API. Deny access
from native code.
Bug: 17787238
Change-Id: Ia337317d5927349b243bbbd5c2cf393911771cdf
The Settings app contains a SystemPropPoker class which notifies every service
on the system that a property has changed.
Address the following denial:
avc: denied { list } for service=NULL scontext=u:r:system_app:s0 tcontext=u:r:servicemanager:s0 tclass=service_manager
Cherry-pick of Change-Id: I81926e8833c1abcb17a4d49687fc89619b416d6c
Bug: 20762975
Change-Id: I665a460f30a1ef57b513da9166aad60097dd4886
The Settings app contains a SystemPropPoker class which notifies every service
on the system that a property has changed.
Address the following denial:
avc: denied { list } for service=NULL scontext=u:r:system_app:s0 tcontext=u:r:servicemanager:s0 tclass=service_manager
Bug: 20762975
Change-Id: I81926e8833c1abcb17a4d49687fc89619b416d6c
