Provide a default label for binfmt_misc. This is not used by the
core policy, although it may be used in device specific policy.
Bug: 20152930
Change-Id: Id51d69333bfeda40720d0e65e1539fab0b6e1e95
On debuggable builds, system_server can request app heap dumps
by running something similar to the following commands:
% adb shell am set-watch-heap com.android.systemui 1048576
% adb shell dumpsys procstats --start-testing
which will dump the app's heap to /data/system/heapdump. See
framework/base commit b9a5e4ad30c9add140fd13491419ae66e947809d.
Allow this behavior.
Addresses the following denial:
avc: denied { write } for path="/data/system/heapdump/javaheap.bin" dev="dm-0" ino=150747 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
Bug: 20073185
Change-Id: I4b925033a5456867caf2697de6c2d683d0743540
Creates new directory at /data/misc/vold for storing key material
on internal storage. Only vold should have access to this label.
Change-Id: I7f2d1314ad3b2686e29e2037207ad83d2d3bf465
- allow access for /data/system/packages.xml.
- deprecate access to /dev/logd_debug (can use /dev/kmsg for debugging)
- allow access to /dev/socket/logd for 'logd --reinit'
Bug: 19681572
Change-Id: Iac57fff1aabc3b061ad2cc27969017797f8bef54
Revert the tightening of /proc/net access. These changes
are causing a lot of denials, and I want additional time to
figure out a better solution.
Addresses the following denials (and many more):
avc: denied { read } for comm="SyncAdapterThre" name="stats" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="facebook.katana" name="iface_stat_fmt" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="IntentService[C" name="if_inet6" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="dumpstate" name="iface_stat_all" dev="proc" ino=X scontext=u:r:dumpstate:s0 tcontext=u:object_r:proc_net:s0 tclass=file
This reverts commit 0f0324cc82
and commit 99940d1af5
Bug: 9496886
Bug: 19034637
Change-Id: I436a6e3638ac9ed49afbee214e752fe2b0112868
allow the bootchart to create dir and files at init,
also allow user to create the stop and start file under
/data/bootchart directory to start and stop bootchart
Change-Id: Icfee8dcd17366383eef00fbe3139744bf4427a6b
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Commit a833763ba0 enabled per-user
isolation, which requires that any files / processes which cross
user boundaries be marked with the mlstrustedsubject attribute.
system_app_data_file, used for storing a user's profile photos,
is not marked as such. As a result, users are unable to add profile
photos.
Addresses the following denial:
avc: denied { write } for path="/data/data/com.android.settings/cache/TakeEditUserPhoto2.jpg" dev="mmcblk0p28" ino=82184 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=file
Steps to reproduce:
1.Flash & Factory the Deb device with tip-of-tree build
2.Go to 'Settings-Users'
3.Under users&profiles,click on Owner to add profile photo.
4.Select 'Choose photo from Gallery' and select a photo.
5.Then click the 'Done' button.
6.Device showed the message as 'Unable to save the photo edits'.
OBSERVED RESULTS:
Unable to add user's profile photo id. This issue is coming for all
users(Restricted user,second user)also.
EXPECTED RESULTS:
Device should allow to add profile photo id.
Bug: 19170844
Change-Id: If657dc09dd391e63ca85320f9cc1728580e51a15
external/sepolicy commit 99940d1af5
(https://android-review.googlesource.com/123331) removed /proc/net
access from domain.te.
Around the same time, system/core commit
9a20e67fa62c1e0e0080910deec4be82ebecc922
(https://android-review.googlesource.com/123531) was checked in.
This change added libnl as a dependency of libsysutils.
external/libnl/lib/utils.c has a function called get_psched_settings(),
which is annotated with __attribute__((constructor)). This code
gets executed when the library is loaded, regardless of whether or
not other libnl code is executed.
By adding the libnl dependency, even code which doesn't use the
network (such as vold and logd) ends up accessing /proc/net/psched.
For now, allow this behavior. However, in the future, it would be
better to break this dependency so the additional code isn't loaded
into processes which don't need it.
Addresses the following denials:
avc: denied { read } for pid=148 comm="logd" name="psched" dev="proc" ino=4026536508 scontext=u:r:logd:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0
avc: denied { read } for pid=152 comm="vold" name="psched" dev="proc" ino=4026536508 scontext=u:r:vold:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0
avc: denied { read } for pid=930 comm="wpa_supplicant" name="psched" dev="proc" ino=4026536508 scontext=u:r:wpa:s0 tcontext=u:object_r:proc_net:s0 tclass=file permissive=0
Bug: 19079006
Change-Id: I1b6d2c144534d3f70f0028ef54b470a75bace1cf
Migrators should be allowed to write to /data/misc/keychain in order
to remove it. Similarly /data/misc/user should be writable by system
apps.
TODO: Revoke zygote's rights to read from /data/misc/keychain on
behalf of some preloaded security classes.
Bug: 17811821
Change-Id: I9e9c6883cff1dca3755732225404909c16a0e547
Resolves denials such as:
avc: denied { write } for pid=1546 comm="Binder_1" name="/" dev="dm-0" ino=2 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:asec_apk_file:s0 tclass=dir
This is required to install a forward-locked app.
Change-Id: I2b37a56d087bff7baf82c738896d9563f0ab4fc4
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In order to support the new goldfish service domains in
a change with the same Change-Id for the build project, we need
the following changes in external/sepolicy:
- /system/bin/logcat needs its own type so that it can be used as an
entrypoint for the goldfish-logcat service. A neverallow rule prevents
us from allowing entrypoint to any type not in exec_type.
- The config. and dalvik. property namespaces need to be labeled
with something other than default_prop so that the qemu-props
service can set them. A neverallow rule prevents us from allowing
qemu-props to set default_prop.
We allow rx_file_perms to logcat_exec for any domain that
was previously allowed read_logd() as many programs will read
the logs by running logcat. We do not do this for all domains
as it would violate a neverallow rule on the kernel domain executing
any file without transitioning to another domain, and as we ultimately
want to apply the same restriction to the init domain (and possibly others).
Change-Id: Idce1fb5ed9680af84788ae69a5ace684c6663974
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.
To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.
This change:
1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.
Addresses the following denial:
avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file
Bug: 17671501
(cherry picked from commit 2de02877a3)
Change-Id: I2c2366bee4fe365288d14bca9778d23a43c368cb
Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.
To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.
This change:
1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.
Addresses the following denial:
avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file
Bug: 17671501
Change-Id: Ib70624fba2baeccafbc0a41369833f76b976ee20
dumpstate and lmkd need to act on apps running at any level.
Various file types need to be writable by apps running at any
level.
Change-Id: Idf574d96ba961cc110a48d0a00d30807df6777ba
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
When using MLS (i.e. enabling levelFrom= in seapp_contexts),
certain domains and types must be exempted from the normal
constraints defined in the mls file. Beyond the current
set, adbd, logd, mdnsd, netd, and servicemanager need to
be able to read/write to any level in order to communicate
with apps running with any level, and the logdr and logdw
sockets need to be writable by apps running with any level.
This change has no impact unless levelFrom= is specified in
seapp_contexts, so by itself it is a no-op.
Change-Id: I36ed382b04a60a472e245a77055db294d3e708c3
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Fix two neverallow rules that yield Invalid SELinux context
warnings from the CTS SELinuxTest.
For transitions from app domains, we only need to check
{ domain -appdomain } (i.e. domains other than app domains),
not ~appdomain (i.e. all types other than app domains). Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing since the target class is process,
and such contexts are invalid.
For keeping file_type and fs_type exclusive, we only need to
check associate permission, not all filesystem permissions, as
only associate takes a file type as the source context. Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing filesystem permissions other than
associate, since the source of such checks is normally a process
context.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
(cherry picked from commit 21ada26dae)
Change-Id: I3346584da9b89f352864dcc30dde06d6bf42e98e
Fix two neverallow rules that yield Invalid SELinux context
warnings from the CTS SELinuxTest.
For transitions from app domains, we only need to check
{ domain -appdomain } (i.e. domains other than app domains),
not ~appdomain (i.e. all types other than app domains). Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing since the target class is process,
and such contexts are invalid.
For keeping file_type and fs_type exclusive, we only need to
check associate permission, not all filesystem permissions, as
only associate takes a file type as the source context. Otherwise
SELinuxTest tries to generate contexts with the r role and
non-domain types for testing filesystem permissions other than
associate, since the source of such checks is normally a process
context.
Change-Id: I6c2f63f4786d75294a6938613ba14b64212fc802
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Rename sdcard_internal/external types to fuse and vfat
respectively to make it clear that they are assigned to any
fuse or vfat filesystem by default (absent a context= mount option)
and do not necessarily represent the SDcard.
The sdcard_type attribute is still assigned to both types and
can still be used in allow rules to permit access to either the
internal or external SDcard.
Define type aliases for the old names to preserve compatibility
on policy reload and for device-specific policies that may not yet
be updated.
Change-Id: I8d91a8c4c1342b94e4f1bb62ca7ffd2ca4b06ba1
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This will be used to populate rt_tables (a mapping from routing table numbers to
table names) that's read by the iproute2 utilities.
Change-Id: I69deb1a64d5d6647470823405bf0cc55b24b22de
The following commits added support for runtime resource overlays.
New command line tool 'idmap'
* 65a05fd56dbc9fd9c2511a97f49c445a748fb3c5
Runtime resource overlay, iteration 2
* 48d22323ce39f9aab003dce74456889b6414af55
Runtime resource overlay, iteration 2, test cases
* ad6ed950dbfa152c193dd7e49c369d9e831f1591
During SELinux tightening, support for these runtime resource
overlays was unknowingly broken. Fix it.
This change has been tested by hackbod and she reports that
everything is working after this change. I haven't independently
verified the functionality.
Test cases are available for this by running:
* python frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1c70484011fd9041bec4ef34f93f7a5509906f40
Several device-specific policy changes with the same Change-Id
also add this attribute to device-specific types.
Change-Id: I09e13839b1956f61875a38844fe4fc3c911ea60f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
It's a bug to have a type with both the file_type and fs_type
attribute. A type should be declared with either file_type,
or fs_type, but not both.
Create a neverallow rule which detects this situation. This works
because we have the following allow rule:
allow fs_type self:filesystem associate;
If a type is a file_type and an fs_type, the associate allow rule
will conflict with this neverallow rule.
Not sure if this is the cleanest way to accomplish this, but it
seems to work.
Change-Id: Ida387b1df260efca15de38ae7a66ed25e353acaa
Right now usbfs doesn't have any labels, generating the
following kernel warnings:
<7>[ 3.009582] SELinux: initialized (dev usbfs, type usbfs), not configured for labeling
and the occasional SELinux unlabeled auditallow logs:
<4>[ 285.579254] type=1400 audit(1402010345.094:16): avc: granted { search } for pid=371 comm="qcks" name="/" dev="usbfs" ino=15794 scontext=u:r:kickstart:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
<4>[ 285.632354] type=1400 audit(1402010345.154:18): avc: granted { search } for pid=371 comm="qcks" name="001" dev="usbfs" ino=15796 scontext=u:r:kickstart:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
Make sure usbfs is assigned via genfscon
Change-Id: I7191f2584014ba55a3c3a98e7efd0350dc958782
/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>
Define a domain and appropriate access rules for shared RELRO files
(used for loading the WebView native library). Any app is permitted to
read the files as they are public data, but only the shared_relro
process is permitted to create/update them.
Bug: 13005501
Change-Id: I9d5ba9e9eedb9b8c80fe6f84a3fc85a68553d52e
installd creates /data/.layout_version. Introduce a separate type
for this file (and any other file created by installd under a directory
labeled system_data_file) so that we can allow create/write access by
installd without allowing it to any system data files created by other
processes. This prevents installd from overwriting other system data
files, and ensure that any files it creates will require explicit
rules in order to access.
Change-Id: Id04e49cd571390d18792949c8b2b13b1ac59c016
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As per the discussion in:
https://android-review.googlesource.com/#/c/92903/
Add sysfs_type attribute to sysfs type so that it is included
in rules on sysfs_type, allow setattr to all sysfs_type for ueventd
for chown/chmod, and get rid of redundant rules.
Change-Id: I1228385d5703168c3852ec75605ed8da7c99b83d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
We were using system_data_file for the /data/data directories of
system UID apps to match the DAC ownership of system UID shared with
other system files. However, we are seeing cases where files created
in these directories must be writable by other apps, and we would like
to avoid allowing write to system data files outside of these directories.
So introduce a separate system_app_data_file type and assign it.
This should also help protect against arbitrary writes by system UID
apps to other system data directories.
This resolves the following denial when cropping or taking a user photo
for secondary users:
avc: denied { write } for path="/data/data/com.android.settings/cache/TakeEditUserPhoto2.jpg" dev="mmcblk0p28" ino=82120 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
avc: denied { write } for path="/data/data/com.android.settings/cache/CropEditUserPhoto.jpg" dev="mmcblk0p30" ino=602905 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
Bug: 14604553
Change-Id: Ifa10e3283b07f6bd6ecc16eceeb663edfd756cea
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Newer adbd versions use functionfs instead of a custom adb usb gadget.
Make sure the functionfs filesystem is properly labeled, and that adbd
has access to the functionfs files.
Once labeled, this addresses the following denials:
<12>[ 16.127191] type=1400 audit(949060866.189:4): avc: denied { read write } for pid=223 comm="adbd" name="ep0" dev="functionfs" ino=5489 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
<12>[ 16.127406] type=1400 audit(949060866.189:5): avc: denied { open } for pid=223 comm="adbd" path="/dev/usb-ffs/adb/ep0" dev="functionfs" ino=5489 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
<12>[ 377.366011] type=1400 audit(949061227.419:16): avc: denied { ioctl } for pid=225 comm="adbd" path="/dev/usb-ffs/adb/ep2" dev="functionfs" ino=5564 scontext=u:r:adbd:s0 tcontext=u:object_r:functionfs:s0 tclass=file
Change-Id: Iee8b522e48b4d677fd12f7c83dbc7ffbc9543ad2
pstore(persistent store) have been applied since kernel 3.5
We need to label the pstore-fs in order to use Android with kernel 3.5 or upper version.
My kernel version is 3.10 and I got the below denial log when I ran the "df" command on the adb shell.
type=1400 msg=audit(1388540540.220:18): avc: denied { getattr } for pid=7296 comm="df" name="/" dev="pstore" ino=7703 scontext=u:r:init:s0 tcontext=u:object_r:unlabeled:s0 tclass=filesystem
And the below log is also shown during booting
type=1400 msg=audit(1388539193.750:4): avc: denied { mount } for pid=2844 comm="mount" name="/" dev="pstore" ino=11393 scontext=u:r:init_shell:s0 tcontext=u:object_r:unlabeled:s0 tclass=filesystem
Change-Id: Iaba543d44565c4f20a77a95b9573a628bbd3fd34
I9b8e59e3bd7df8a1bf60fa7ffd376a24ba0eb42f added a profiles
subdirectory to /data/dalvik-cache with files that must be
app-writable. As a result, we have denials such as:
W/Profiler( 3328): type=1400 audit(0.0:199): avc: denied { write } for name="com.google.android.setupwizard" dev="mmcblk0p28" ino=106067 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
W/Profiler( 3328): type=1300 audit(0.0:199): arch=40000028 syscall=322 per=800000 success=yes exit=33 a0=ffffff9c a1=b8362708 a2=20002 a3=0 items=1 ppid=194 auid=4294967295 uid=10019 gid=10019 euid=10019 suid=10019 fsuid=10019 egid=10019 sgid=10019 fsgid=10019 tty=(none) ses=4294967295 exe="/system/bin/app_process" subj=u:r:untrusted_app:s0 key=(null)
W/auditd ( 286): type=1307 audit(0.0:199): cwd="/"
W/auditd ( 286): type=1302 audit(0.0:199): item=0 name="/data/dalvik-cache/profiles/com.google.android.setupwizard" inode=106067 dev=b3:1c mode=0100664 ouid=1012 ogid=50019 rdev=00:00 obj=u:object_r:dalvikcache_data_file:s0
We do not want to allow untrusted app domains to write to the
existing type on other /data/dalvik-cache files as that could be used
for code injection into another app domain, the zygote or the system_server.
So define a new type for this subdirectory. The restorecon_recursive /data
in init.rc will fix the labeling on devices that already have a profiles
directory created. For correct labeling on first creation, we also need
a separate change to installd under the same change id.
Bug: 13927667
Change-Id: I4857d031f9e7e60d48b8c72fcb22a81b3a2ebaaa
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This appears to have been created to allow untrusted_app to
access DownloadProvider cache files without needing to allow
open access to platform_app_data_file. Now that platform_app_data_file
is gone, there is no benefit to having this type.
Retain a typealias for download_file to app_data_file until
restorecon /data/data support is in place to provide compatibility.
This change depends on:
https://android-review.googlesource.com/#/c/87801/
Change-Id: Iab3c99d7d5448bdaa5c1e03a98fb6163804e1ec4
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The original concept was to allow separation between /data/data/<pkgdir>
files of "platform" apps (signed by one of the four build keys) and
untrusted apps. But we had to allow read/write to support passing of
open files via Binder or local socket for compatibilty, and it seems
that direct open by pathname is in fact used in Android as well,
only passing the pathname via Binder or local socket. So there is no
real benefit to keeping it as a separate type.
Retain a type alias for platform_app_data_file to app_data_file until
restorecon /data/data support is in place to provide compatibility.
Change-Id: Ic15066f48765322ad40500b2ba2801bb3ced5489
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change I6dacdc43bcc1a56e47655e37e825ee6a205eb56b switched
the keystore to using binder instead of a socket, so this
socket type and rules have been unused for a while. The type
was only ever assigned to a /dev/socket socket file (tmpfs) so
there is no issue with removing the type (no persistent files
will have this xattr value).
Change-Id: Id584233c58f6276774c3432ea76878aca28d6280
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
