This prevents denials while taking a bugreport.
Test: cts-tradefed run cts -m CtsSecurityHostTestCases -t
android.security.cts.SELinuxHostTest#testNoBugreportDenials
Change-Id: I381b39fa127f82fcef5d820a04209fd1ba4f63cd
Allow BLKROGET and BLKROSET on the block devices underlying the /system
and rootfs partitions. As part of the Android boot process, the system
sets the block devices read-only to prevent accidental modification to
these partitions. Update engine needs the ability to adjust the block
device read-only flag in order to apply updates.
Addresses the following denials:
update_engine: type=1400 audit(0.0:96): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125e scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:97): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125d scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
Test: policy compiles
Bug: 118150702
Change-Id: I65a3d041b6d6b7955bcd901637a543524fc34a06
system/sepolicy commit 4c8eaba75a, reviewed in
https://android-review.googlesource.com/c/platform/system/sepolicy/+/793958
started enforcing explicit ioctl permission checks for all block device
files. As part of that commit, the following lines were added to
domain.te:
# If a domain has access to perform an ioctl on a block device, allow these
# very common, benign ioctls
allowxperm domain dev_type:blk_file ioctl { BLKGETSIZE64 BLKSSZGET };
In essence, if a domain is granted ioctl access to any device in
policy (for example, via adding "ioctl" to the allow rule, or by using
the macro "r_file_perms" which includes the ioctl permission), then the
two ioctls BLKGETSIZE64 and BLKSSZGET will be automatically allowed. As
such, it is redundent for a domain to explicitly request these two
ioctls.
Delete the now redundant allowxperm rule.
Test: policy compiles
Change-Id: I1964ed93a7c7601393cc9e2416f3640ea22db51b
What changed:
- Tightening neverallow forbidding vendor execution access in /system.
In it's current form the neverallow is loose because not all executables
have exec_type attribute, e.g. almost everything in /system/bin/. This
change tightens up the neverallow by instead targeting system_file_type
attribute, which must be applied to all files in /system.
- Adding a general neverallow forbidding all access to files in /system
(bar exceptions)
TODOs:
- Remove loopholes once Treble violations are fixed across all internal
build targets.
Bug: 111243627
Test: m selinux_policy; build-only change
Change-Id: I150195756c0c3258904c3da0812bbd942ea2f229
This change assumes that init need access to types, access to which
was not audited.
go/sedenials reports additional types needed by init: pmsg_device and
tty_device.
Bug: 110962171
Test: m selinux_policy
Change-Id: I227956b2c12efeef68cbfa041b9604d4e4f9b967
Start enforcing the use of ioctl restrictions on all Android block
devices. Domains which perform ioctls on block devices must be explicit
about what ioctls they issue. The only ioctls allowed by default are
BLKGETSIZE64, BLKSSZGET, FIOCLEX, and FIONCLEX.
Test: device boots and no problems.
Change-Id: I1195756b20cf2b50bede1eb04a48145a97a35867
Remove most of /proc/net access for priv_apps. Files in /proc/net leak
unique device identifiers and side channel information about other app's
network connections.
Access for most third party applications was removed in commit
d78e07cbb7. This change applies the same
constraints to priv-apps that we apply to normal apps.
Bug: 114475727
Bug: 9496886
Bug: 68016944
Test: policy compiles and device boots
Change-Id: I5c41ba57fcd6b81d72c4f3a40b310d2188fc79c3
Allow a process to determine if a fifo_file (aka pipe, created from the
pipe() or pipe2() syscall) is a tty.
Addresses the following denials:
type=1400 audit(0.0:1307): avc: denied { ioctl } for comm="ls" path="pipe:[213117]" dev="pipefs" ino=213117 ioctlcmd=5401 scontext=u:r:hal_dumpstate_impl:s0 tcontext=u:r:hal_dumpstate_impl:s0 tclass=fifo_file permissive=0
type=1400 audit(0.0:22): avc: denied { ioctl } for comm="sh" path="pipe:[54971]" dev="pipefs" ino=54971 ioctlcmd=5401 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:r:untrusted_app_27:s0:c512,c768 tclass=fifo_file permissive=0 app=com.zhihu.android
type=1400 audit(0.0:237): avc: denied { ioctl } for comm="sh" path="pipe:[56997]" dev="pipefs" ino=56997 ioctlcmd=5401 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:r:untrusted_app_25:s0:c512,c768 tclass=fifo_file permissive=0 app=fm.qingting.qtradio
Test: policy compiles and device builds.
Change-Id: Ic4c6441d0ec33de8cda3f13ff529e98374897364
apexd uses realpath(3) to ensure that the public key file that will use
is under /system/etc/security/apex directory. In order to support it,
allow apexd to getattr on apex_key_files.
The canonicalization is required because the key name from APEX might be
wrong. For example, if the key name from an APEX is '../../some/path'
then apexd will use '/system/etc/security/apex/../../some/path' as the
public key file, which is incorrect.
Bug: 115721587
Test: m apex.test; m
/apex/com.android.example.apex@1 exists
Change-Id: I6dc5efa0de369f8497e4f6526e0164e2de589c67
When running some apps in vendor partition, it report denials like:
avc: denied { getattr } for comm="Binder:901_2" path="/vendor/operator/app/Wechat/Wechat.apk" dev="sde14" ino=1707 scontext=u:r:mediaserver:s0 tcontext=u:object_r:vendor_app_file:s0 tclass=file permissive=0
What changed:
- Tightening neverallow forbidding vendor execution access in /system.
In it's current form the neverallow is loose because not all executables
have exec_type attribute, e.g. almost everything in /system/bin/. This
change tightens up the neverallow by instead targeting system_file_type
attribute, which must be applied to all files in /system.
- Adding a general neverallow forbidding all access to files in /system
(bar exceptions)
TODOs:
- Remove loopholes once Treble violations are fixed across all internal
build targets.
Bug: 111243627
Test: m selinux_policy; build-only change
Change-Id: Ic8d71c8d139cad687ad7d7c9db7111240475f175
Add a neverallow rule requiring fine-grain ioctl filtering for most file
and socket object classes. Only chr_file and blk_file are excluded. The
goal is to ensure that any file descriptor which supports ioctl commands
uses a whitelist.
Further refine the list of file / socket objects which require ioctl
filtering. The previous ioctl filtering did not cover the following:
1) ioctls on /proc/PID files
2) ioctls on directories in /dev
3) PDX unix domain sockets
Add FIONCLEX to the list of globally safe ioctls. FIOCLEX and FIONCLEX
are alternate, uncommon ways to set the O_CLOEXEC flag on a file
descriptor, which is a harmless operation.
Test: device boots and no problems.
Change-Id: I6ba31fbe2f21935243a344d33d67238d72a8e618
Input config should be under /odm when it's "device-specific",
instead of /vendor (for "SoC-specific").
However, not all device have /odm partition so having the fallback
symlink: /odm -> /vendor/odm is important
Bug: 112880217
Test: build
Change-Id: I294e2b172d06d58a42c51c128e448c7644f854dc
Kernel commit 3ba4bf5f1e2c ("selinux: add a map permission check for
mmap") added a map permission check on mmap so that we can
distinguish memory mapped access (since it has different implications
for revocation). The purpose of a separate map permission check on
mmap(2) is to permit policy to prohibit memory mapping of specific
files for which we need to ensure that every access is revalidated,
particularly useful for scenarios where we expect the file to be
relabeled at runtime in order to reflect state changes (e.g.
cross-domain solution, assured pipeline without data copying).
system/sepolicy commit 4397f08288 added
the map permission to common file macros, to ensure that file access
would continue working even in the presence of a newer kernel. However,
that change did not affect socket access.
Certain socket classes, such as AF_NETLINK and AF_PACKET, also support
mmap operations. This change adds the map permission to rw_socket_perms,
to ensure continued support for newer kernels.
This technically allows mmap even in cases where the socket family
doesn't support it (such as TCP and UDP sockets), but granting it
is harmless in those cases.
In particular, this fixes a bug in clatd, where the following error
would occur:
10-01 13:59:03.182 7129 7129 I clatd : Starting clat version 1.4 on rmnet0 netid=100 mark=0xf0064
10-01 13:59:03.195 7129 7129 I auditd : type=1400 audit(0.0:18): avc: denied { map } for comm="clatd" path="socket:[52802]" dev="sockfs" ino=52802 scontext=u:r:clatd:s0 tcontext=u:r:clatd:s0 tclass=packet_socket permissive=0
10-01 13:59:03.195 7129 7129 W clatd : type=1400 audit(0.0:18): avc: denied { map } for path="socket:[52802]" dev="sockfs" ino=52802 scontext=u:r:clatd:s0 tcontext=u:r:clatd:s0 tclass=packet_socket permissive=0
10-01 13:59:03.199 7129 7129 F clatd : mmap 1048576 failed: Permission denied
Test: policy compiles
Bug: 117791876
Change-Id: I39f286d577b4a2160037ef271517ae8a3839b49b
