We allow chmod/chown of files / directories by init, but don't allow
init to search into subdirectories. Feels wrong.
Addresses the following denial:
avc: denied { search } for pid=1 comm="init" name="/" dev="pstore" ino=5570 scontext=u:r:init:s0 tcontext=u:object_r:pstorefs:s0 tclass=dir permissive=1
which results from the following init.rc statement:
# pstore/ramoops previous console log
mount pstore pstore /sys/fs/pstore
chown system log /sys/fs/pstore/console-ramoops
chmod 0440 /sys/fs/pstore/console-ramoops
chown system log /sys/fs/pstore/pmsg-ramoops-0
chmod 0440 /sys/fs/pstore/pmsg-ramoops-0
Bug: 19050686
Change-Id: I0528ecb17686891b66262de1f3c229cc68a56830
The shell domain is already allowed to list and find all service_manager
objects, so extra auditing is pointless.
Bug: 18106000
Change-Id: I8dbf674fa7ea7b05e48e5bbc352b0c9593f2b627
Also, divide each sepolicy-analyze function into its own component for simplified
command-line parsing and potentially eventual modularization.
Bug: 18005561
Cherry-pick of commit: ef4fd30672
with commit: 47c1461156
squashed in.
Bug: 19191637
Change-Id: Id66cad549b7311a6bbd92fd64b6ec2c60d0433a4
Relax the neverallow netlink restrictions for app domains.
In particular, some non-AOSP app domains may use netlink sockets
to communicate with a kernel driver.
Continue to neverallow generic netlink sockets for untrusted_app.
The intention here is that only app domains which explicitly need
this functionality should be able to request it.
This change does not add or remove any SELinux rules. Rather, it
just changes SELinux compile time assertions, as well as allowing
this behavior in CTS.
Modify other neverallow rules to use "domain" instead of "self".
Apps shouldn't be able to handle netlink sockets, even those
created in other SELinux domains.
(cherry picked from commit d31936f89c)
Change-Id: I4763cb0c9510220693c506636dbb7584712b67e2
See NEVERALLOW CHECKING in tools/README for documentation.
Depends on change I45b3502ff96b1d093574e1fecff93a582f8d00bd
for libsepol to support reporting all neverallow failures.
Cherry-pick of commit: 59906bf893
with build-fix from commit: 74bbf703df
added manually.
Bug: 19191637
Change-Id: I1c18fa854b3c5f5e05d5dc42d9006c5fdacebdc3
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Without this change, any selinux warning you might get when running
dumpstate from init do not show up when running from the shell
as root. This change makes them run the same.
Change-Id: I6b74e0f6f48f47952a2dbe7728b1853008f60dbb
Address the following denial:
SELinux E avc: denied { find } for service=drm.drmManager scontext=u:r:radio:s0 tcontext=u:object_r:drmserver_service:s0
which occurs when a non-default SMS app sends an MMS. The message would be
stored into system automatically in MMS service (from phone process and phone
UID). The storing of the message involves the creation of
android.drm.DrmManagerClient instance.
Change-Id: Ic4e493f183c9ce7f7ac3f74f6ea062893ea67608
Add an SELinux neverallow rule (compile time assertion) that only
authorized SELinux domains are writing to files in /data/dalvik-cache.
Currently, SELinux policy only allows the following SELinux domains
to perform writes to files in /data/dalvik-cache
* init
* zygote
* installd
* dex2oat
For zygote, installd, and dex2oat, these accesses make sense.
For init, we could further restrict init to just relabelfrom
on /data/dalvik-cache files, and { create, write, setattr }
on /data/dalvik-cache directories. Currently init has full
write access, which can be reduced over time.
This change was motivated by the discussion
in https://android-review.googlesource.com/127582
Remove /data/dalvik-cache access from the unconfined domain.
This domain is only used by init, kernel, and fsck on user builds.
The kernel and fsck domains have no need to access files in
/data/dalvik-cache. Init has a need to relabel files, but
that rule is already granted in init.te.
The neverallow rule is intended to prevent regressions. Neverallow
rules are CTS tested, so regressions won't appear on our devices
or partner devices.
Change-Id: I15e7d17b1121c556463114d1c6c49557a57911cd
system_server should never be executing dex2oat. This is either
a bug (for example, bug 16317188), or represents an attempt by
system server to dynamically load a dex file, something we don't
want to allow.
This change adds a compile time assertion which will detect
if an allow rule granting this access is ever added.
No new rules are added or deleted as a result of this change.
This neverallow rule is automatically enforced via CTS.
Bug: 16317188
Change-Id: Id783e05d9f48d48642dbb89d9c78be4aae8af70c
Relax the neverallow netlink restrictions for app domains.
In particular, some non-AOSP app domains may use netlink sockets
to communicate with a kernel driver.
Continue to neverallow generic netlink sockets for untrusted_app.
The intention here is that only app domains which explicitly need
this functionality should be able to request it.
This change does not add or remove any SELinux rules. Rather, it
just changes SELinux compile time assertions, as well as allowing
this behavior in CTS.
Modify other neverallow rules to use "domain" instead of "self".
Apps shouldn't be able to handle netlink sockets, even those
created in other SELinux domains.
(cherry picked from commit d31936f89c)
Bug: 19198997
Change-Id: Icfed1ee66f082df1117b090341f62981f01bc849
Relax the neverallow netlink restrictions for app domains.
In particular, some non-AOSP app domains may use netlink sockets
to communicate with a kernel driver.
Continue to neverallow generic netlink sockets for untrusted_app.
The intention here is that only app domains which explicitly need
this functionality should be able to request it.
This change does not add or remove any SELinux rules. Rather, it
just changes SELinux compile time assertions, as well as allowing
this behavior in CTS.
Modify other neverallow rules to use "domain" instead of "self".
Apps shouldn't be able to handle netlink sockets, even those
created in other SELinux domains.
Change-Id: I40de0ae28134ce71e808e5ef4a39779b71897571
Messenger can't send MMSes on the master branch. When Messenger sends
an MMS, it stores the message data in local file and publishes it
via a content provider. The URI is passed to the MMS API. The
MmsServiceBroker in system process gets the call and grant URI
permission to phone UID. The MmsService in phone process (and sharing
the phone UID) needs to read the URI to get message data to send.
Addresses the following denial:
type=1400 audit(0.0:32): avc: denied { read } for path="/data/data/com.google.android.apps.messaging/cache/rawmms/5394791820000274558.dat" dev="mmcblk0p28" ino=83180 scontext=u:r:radio:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
Change-Id: I2b694ff6c516714d3524e0613bae0f6773ed2e95
