And also remove the unnecessary references to libselinux for
sepolicy-check, as it has no dependencies on libselinux.
Also enable -Wall -Werror on building all of these tools and
fix up all such errors.
Usage:
$ sepolicy-analyze -e -P out/target/product/<device>/root/sepolicy
or
$ sepolicy-analyze -d -P out/target/product/<device>/root/sepolicy
The first form will display all type pairs that are "equivalent", i.e.
they are identical with respect to allow rules, including indirect allow
rules via attributes and default-enabled conditional rules (i.e. default
boolean values yield a true conditional expression).
Equivalent types are candidates for being coalesced into a single type.
However, there may be legitimate reasons for them to remain separate,
for example:
- the types may differ in a respect not included in the current
analysis, such as default-disabled conditional rules, audit-related
rules (auditallow or dontaudit), default type transitions, or
constraints (e.g. mls), or
- the current policy may be overly permissive with respect to one or the
other of the types and thus the correct action may be to tighten access
to one or the other rather than coalescing them together, or
- the domains that would in fact have different accesses to the types
may not yet be defined or may be unconfined in the policy you are
analyzing (e.g. in AOSP policy).
The second form will display type pairs that differ and the first
difference found between the two types. This output can be long.
We have plans to explore further enhancements to this tool, including
support for identifying isomorphic types. That will be required to
identify similar domains since all domains differ in at least their
entrypoint type and in their tmpfs type and thus will never show up as
equivalent even if they are in all other respects identical to each other.
Change-Id: If0ee00188469d2a1e165fdd52f235c705d22cd4e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Some bluetooth implementations write to bluetooth.* properties.
It seems reasonable to allow this for all bluetooth implementations.
This addresses the following denial (seen on mako):
<4>[ 132.182755] avc: denied { set } for property=bluetooth.hciattach scontext=u:r:bluetooth:s0 tcontext=u:object_r:bluetooth_prop:s0 tclass=property_service
Change-Id: I6d92c0ff108838dd1107c5fb3c436699ef824814
Since Change-Id: If4f169d9ed4f37b6ebd062508de058f3baeafead
the insert_keys.py tool has had support for expanding
environment variable strings. This change addresses the lack
of an updated README covering said change.
Change-Id: I88e81ea58fb84110da3fc3cfb8b49fd0d6c027c2
In 9af6f1bd59, the -d option
was dropped from insertkeys.py. This was done to allow an
Android distribution to replace the default version of
keys.conf distributed in external/sepolicy/keys.conf. keys.conf
was modified to reference the publicly known test keys in
build/target/product/security.
Unfortunately, this broke Google's build of Android. Instead
of incorporating our keys directory, we were using the
default AOSP keys. As a result, apps were getting assigned
to the wrong SELinux domain. (see "Steps to reproduce" below)
This change continues to allow others to replace keys.conf,
but makes DEFAULT_SYSTEM_DEV_CERTIFICATE available as an
environment variable in case the customized version wants to
make reference to it. This change also modifies the stock
version of keys.conf to use DEFAULT_SYSTEM_DEV_CERTIFICATE,
which should be appropriate for most Android distributions.
It doesn't make any sense to force each OEM to have a copy of
this file.
Steps to reproduce.
1) Compile and boot Android.
2) Run the following command: "adb shell ps -Z | grep process.media"
Expected:
$ adb shell ps -Z | grep process.media
u:r:media_app:s0 u0_a5 1332 202 android.process.media
Actual:
$ adb shell ps -Z | grep process.media
u:r:untrusted_app:s0 u0_a5 3617 187 android.process.media
Bug: 11327304
Change-Id: Ica24fb25c5f9c0e2f4d181718c757cf372467822
Confine the mediaserver domain, restoring our rules for it,
but leave it permissive until sufficient testing has been
performed.
Change-Id: I3d10ee16f5125b11295bc40ff6f2e14080b4bd00
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As has already been done for untrusted_app, isolated_app,
and bluetooth, make all the other domains used for app
processes confined while making them permissive until sufficient
testing has been done.
Change-Id: If55fe7af196636c49d10fc18be2f44669e2626c5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove unconfined_domain() from the bluetooth app domain,
restore the rules from our policy, and move the neverallow
rule for bluetooth capabilities to bluetooth.te.
Make the bluetooth domain permissive again until it has
received sufficient testing.
Change-Id: I3b3072d76e053eefd3d0e883a4fdb7c333bbfc09
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In https://android-review.googlesource.com/66562 , there
was a discussion about the role the unconfined template
plays. Document the unconfined template so that those
expectations are better understood.
Change-Id: I20ac01ac2d4496b8425b6f63d4106e8021bc9b2f
This change removes the permissive line from unconfined
domains. Unconfined domains can do (mostly) anything, so moving
these domains into enforcing should be a no-op.
The following domains were deliberately NOT changed:
1) kernel
2) init
In the future, this gives us the ability to tighten up the
rules in unconfined, and have those tightened rules actually
work.
When we're ready to tighten up the rules for these domains,
we can:
1) Remove unconfined_domain and re-add the permissive line.
2) Submit the domain in permissive but NOT unconfined.
3) Remove the permissive line
4) Wait a few days and submit the no-permissive change.
For instance, if we were ready to do this for adb, we'd identify
a list of possible rules which allow adbd to work, re-add
the permissive line, and then upload those changes to AOSP.
After sufficient testing, we'd then move adb to enforcing.
We'd repeat this for each domain until everything is enforcing
and out of unconfined.
Change-Id: If674190de3262969322fb2e93d9a0e734f8b9245
Modify check_seapp.c to verify that a packagname (name)
must be specified with a signing key (seinfo). This will
help thwart spoof attacks on the packagename.
Change-Id: I8f1aa8a479cb5beb5c3522d85e3181604931ea72
check_seapp at one point in time switch from a home implementation
of a hash table to using GLIBC search.h routines. A struct in one
of the fields was never removed during this transition.
Change-Id: I65c028103ffe90fa52e0b3c9fce28124ed9c7ff9
insertkeys.py used beginswith() when checking that the BEGIN
and END CERTIFICATE clauses in PEM files were correct. It should
have done an explicit check on equality.
Change-Id: I5efb48d180bc674e6281a26a955acd248588b8bd
Many keys end with whitespace or otherwise have whitespace separating the
certificates. If insertkeys is intended to support multiple certificates, we
should also support blank line separators.
Change-Id: I5fd17be5785ad1b89a6191e9ba33bbc7c5a4e8e9
Insert keys would erroneously process pem files
with openssl headers in them. Also, the tool would
be fooled into attempting to use pem files that
had private keys and other things in the format.
This patch strengthens the formatting requirements
and increases the verboseness of error messages
when processing pem files.
Change-Id: I03353faaa641233a000d1a18943024ae47c63e0f
* Keep ueventd in permissive
* Drop unconfined macro to collect logs
* Restore allow rules to current NSA maintained policy
Change-Id: Ic4ee8e24ccd8887fed151ae1e4f197512849f57b
/dev/hw_random is accessed only by init and by EntropyMixer (which
runs inside system_server). Other domains are denied access because
apps/services should be obtaining randomness from the Linux RNG.
Change-Id: Ifde851004301ffd41b2189151a64a0c5989c630f
The /adb_keys entry will only take effect if a restorecon is
applied by init.rc on a kernel that includes the rootfs labeling
support, but does no harm otherwise.
The /data/misc/adb labeling ensures correct labeling of the adb_keys
file created if the device has ro.adb.secure=1 set.
Allow adbd to read the file.
Change-Id: I97b3d86a69681330bba549491a2fb39df6cf20ef
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change I4be1c987a5d69ac784a56d42fc2c9063c402de11 removed all
netdomain allow rules at the same time domains were made unconfined.
Prior to that change, any domain that used the net_domain() macro
would be granted permissions required to use the network via these rules.
The change made the netdomain attribute unused in any rules, thereby
rendering the net_domain() calls pointless and requiring the allow
rules to be duplicated for any domain requiring network access. There
are two ways to resolve this inconsistency:
1. Restore the netdomain rules as in this change. In that case,
some rules in app.te can be removed as they are redundant with these rules.
-or-
2. Completely remove the netdomain attribute, the net_domain() macro,
and all calls to it. In that case, each domain that requires network
access will need to duplicate these rules or the necessary subset in order
to function.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change-Id: Ia54f0cd0bbda5c510423b1046626bd50f79ed7b6
Shell domain can transition to other domains for runas, ping, etc.
Change-Id: If9aabb4f51346dc00a89d03efea25499505f278d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This change synchronizes the AOSP set of neverallow rules for
app domains with our own. However, as we exclude unconfineddomain
from each neverallow rule, it causes no breakage in the AOSP policy.
As app domains are confined, you will need to either adjust the
app domain or the neverallow rule according to your preference.
But our policy builds with all of these applied with all app domains
confined.
Change-Id: I00163d46a6ca3a87e3d742d90866300f889a0b11
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Otherwise it defaults to the label of /data/system and
cannot be distinguished from any other socket in that directory.
Also adds allow rule required for pre-existing wpa_socket transition
to function without unconfined_domain.
Change-Id: I57179aa18786bd56d247f397347e546cca978e41
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Some file types used as domain entrypoints were missing the
exec_type attribute. Add it and add a neverallow rule to
keep it that way.
Change-Id: I7563f3e03940a27ae40ed4d6bb74181c26148849
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change-Id I027f76cff6df90e9909711cb81fbd17db95233c1 added a
/data/local/tmp/selinux entry at the same time domains were made
permissive. I do not know why, and do not see how this is used.
So remove it.
Change-Id: I3218cc18de9781bc65ae403f2cf4c234847ef5f5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add a create_pty() macro that allows a domain to
create and use its own ptys, isolated from the ptys
of any other domain, and use that macro for untrusted_app.
This permits the use of a pty by apps without opening up access
to ptys created by any other domain on the system.
Change-Id: I5d96ce4d1b26073d828e13eb71c48d1e14ce7d6b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
These device nodes were specific to crespo / Nexus S and
if ever needed again, should be re-introduced in the per-device
sepolicy, not here.
Change-Id: I8366de83967974122c33937f470d586d49c34652
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This is now possible due to the kernel change to support
setting security contexts on rootfs inodes.
Change-Id: I2a9aac1508eceabb92c3ae8eb5c63a16b28dda6f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The type was already defined and used in type transitions for cases
where the gps socket is created at runtime by gpsd, but on some devices
it is created by init based on an init.<board>.rc socket entry and therefore
needs a file_contexts entry.
Before:
$ ls -Z /dev/socket/gps
srw-rw---- gps system u:object_r:device:s0 gps
After:
$ ls -Z /dev/socket/gps
srw-rw---- gps system u:object_r:gps_socket:s0 gps
Change-Id: I8eef08d80e965fc4f3e9dd09d4fa446aaed82624
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Otherwise it gets left in the general device type, and we get denials such
as:
type=1400 msg=audit(1379617262.940:102): avc: denied { write } for pid=579 comm="mDnsConnector" name="mdns" dev="tmpfs" ino=3213 scontext=u:r:system_server:s0 tcontext=u:object_r:device:s0 tclass=sock_file
This of course only shows up if using a confined system_server.
Change-Id: I2456dd7aa4d72e6fd15b55c251245186eb54a80a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This CL completes the renaming of domain system to system_server by
removing the "system" typealias that was temporarily added to avoid
breaking the build while the rename CLs are landing.
Change-Id: I05d11571f0e3d639026fcb9341c3476d44c54fca