Rewrote the process policy in external/sepolicy/unconfined.te
from a blacklist to a whitelist to be more easily understood.
There were previously 11 disallowed permissions and now there are
19 allowed permissions.
Change-Id: Ida4dc881c5fedc56980324774f40e09a9b8a830a
The selinux_version file is used to perform policy
versioning checks by libselinux and SELinuxMMAC. When
loading policy a check is first performed to determine
if the policy out in /data/security/current should be
used to override the base policy shipped with the device.
The selinux_version file is used to make that choice. The
contents of the file simply contains the BUILD_FINGERPRINT
that the policy was built against. A simple string comparison
is then performed by libselinux and SELinuxMMAC.
Change-Id: I69d9d071743cfd46bb247c98f94a193396f8ebbd
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Remove /data/security and setprop selinux.reload_policy access
from unconfineddomain, and only add back what is needed to
init (system_server already gets the required allow rules via
the selinux_manage_policy macro).
init (via init.rc post-fs-data) originally creates /data/security
and may later restorecon it. init also sets the property (also from
init.rc post-fs-data) to trigger a reload once /data is mounted.
The system_server (SELinuxPolicyInstallReceiver in particular) creates
subdirectories under /data/security for updates, writes files to these
subdirectories, creates the /data/security/current symlink to the update
directory, and sets the property to trigger a reload when an update bundle
is received.
Add neverallow rules to ensure that we do not allow undesired access
to security_file or security_prop.
This is only truly meaningful if the support for /data/security policies
is restored, but is harmless otherwise.
Also drop the persist.mmac property_contexts entry; it was never used in
AOSP, only in our tree (for middleware MAC) and is obsolete.
Change-Id: I5ad5e3b6fc7abaafd314d31723f37b708d8fcf89
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Create a separate recovery policy and only include the
recovery domain allow rules in it.
Change-Id: I444107f9821eabf4164ba07a44d03bd71e719989
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
These permissions are already allowed indirectly via unconfineddomain
and via domain, but ultimately we plan to remove them from those two
attributes. Explicitly allow the ones we expect to be required,
matching the complement of the auditallow rules in domain.te.
Change-Id: I43edca89d59c159b97d49932239f8952a848031c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
https://android-review.googlesource.com/#/c/95900/ added further
unlabeled rules for installd and added explicit unlabeled rules for
vold and system_server. Exclude these permissions from the auditallow
rules on unlabeled so that we only see the ones that would be denied if
we were to remove the allow domain rules here.
Change-Id: I2b9349ad6606bcb6a74a7e67343a8a9e5d70174c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The bugs that motivated bringing back the unlabeled allowall rules,
https://android-review.googlesource.com/#/c/94971/
should be resolved by the following changes:
https://android-review.googlesource.com/#/c/94966/https://android-review.googlesource.com/#/c/96080/
Beyond those changes, installd needs to be able to remove package directories
for apps that no longer exist or have moved (e.g. to priv-app) on upgrades, so
allow it the permissions required for this purpose. vold needs to be able
to chown/chmod/restorecon files in asec containers so allow it the
permissions to do so. system_server tries to access all /data/data
subdirectories so permit it to do so. installd and system_server
read the pkg.apk file before it has been relabeled by vold and therefore
need to read unlabeled files.
Change-Id: I70da7d605c0d037eaa5f3f5fda24f5e7715451dc
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Narrow the relabelto rules to a more specific type set
for each domain.
Drop mount permissions from the kernel domain since mounting
occurs after switching to the init domain. This was likely
a residual of when all processes were left in the kernel domain
on a recovery boot due to the missing setcon statement in the
recovery init.rc.
Be consistent with unlabeled filesystems (i.e. filesystems
without any matching fs_use or genfs_contexts entry) so
that we can also unmount them.
Add comments to note the reason for various rules.
Change-Id: I269a1744ed7bf8c6be899494c5dc97847e5a994d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Don't allow writes to /system from unconfined domains.
/system is always mounted read-only, and no process should
ever need to write there.
Allow recovery to write to /system. This is needed to apply OTA
images.
Change-Id: I11aa8bd0c3b7f53ebe83806a0547ab8d5f25f3c9
/data/property is only accessible by root and is used by the init
property service for storing persistent property values. Create
a separate type for it and only allow init to write to the directory
and files within it. Ensure that we do not allow access to other domains
in future changes or device-specific policy via a neverallow rule.
Change-Id: Iff556b9606c5651c0f1bba902e30b59bdd6f063a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Resolves denials such as:
avc: denied { set } for property=ril.cdma.inecmmode scontext=u:r:radio:s0 tcontext=u:object_r:rild_prop:s0 tclass=property_service
This makes ril.cdma consistent with net.cdma.
We may ultimately need to coalesce rild_prop and radio_prop; they
were an attempt to distinguish what can be set by rild from what can be
set by com.android.phone, but the init property service DAC checking
permits any of them to be set by anything with the radio AID. We
presently allow rild to set either type, but radio can only set radio_prop.
Change-Id: Ia3852db187e52427e18075e24b2beab19dd59c1f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As suggested in https://android-review.googlesource.com/95966 , remove
various syslog_* from unconfined. SELinux domains which want to use
syslog_* can declare it themselves.
Change-Id: I7a8335850d1b8d3463491b4ef8c657f57384cfa4
Allow the shell user to see the dmesg output. This data is already
available via "adb bugreport", but isn't easy to access.
Bug: 10020939
Change-Id: I9d4bbbd41cb02b707cdfee79f826a39c1ec2f177
