When the InputProcessor HAL is getting dumped, allow the dumpstate
process to trigger the trace collection.
In the future, we will also add a 'dump' facility to this HAL.
Bug: 237347585
Bug: 237322365
Test: adb bugreport
Change-Id: Iecc525c212c1b899962a032df9643bdd8b0dcdb6
(to be able to stat() nodes in /sys/fs/bpf)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic71ebea683844a8d5ac0b542da815bae2816973a
A crosvm instance running a protected VM contains a memory mapping of
the VM's protected memory. crash_dump can trigger a kernel panic if it
attaches to such crosvm instance and tries to dump this memory region.
Until we have a means of excluding only the protected memory from
crash_dump, prevent crash_dump from dumping crosvm completely by taking
away its SELinux permission to ptrace crosvm.
Bug: 236672526
Test: run 'killall -s SIGSEGV crosvm' while running crosvm
Change-Id: I6672746c479183cc2bbe3dce625e5b5ebcf6d822
Access to this functionality is gated elsewhere e.g. by
allowing/disallowing access to the service.
Bug: 237512474
Test: IpSecManagerTest
Test: Manual with GMSCore + PPN library
Change-Id: Ibb00b7c470a4cb148cfdcfb6b147edde45e49b1a
Like the non-persistent variants, should be settable by shell without
root to allow external developer use on locked bootloaders.
Bug: 236738714
Test: atest bionic-unit-tests
Change-Id: Id9fc4abe491f560134267b06dd53c2dacca9422d
* changes:
sepolicy: allow TUNSETLINK and TUNSETCARRIER
Add xfrm netlink permissions for system server
Fix system server and network stack netlink permissions
Goal is to gain a better handle on who has access to which maps
and to allow (with bpfloader changes to create in one directory
and move into the target directory) per-map selection of
selinux context, while still having reasonable defaults for stuff
pinned directly into the target location.
BPFFS (ie. /sys/fs/bpf) labelling is as follows:
subdirectory selinux context mainline usecase / usable by
/ fs_bpf no (*) core operating system (ie. platform)
/net_private fs_bpf_net_private yes, T+ network_stack
/net_shared fs_bpf_net_shared yes, T+ network_stack & system_server
/netd_readonly fs_bpf_netd_readonly yes, T+ network_stack & system_server & r/o to netd
/netd_shared fs_bpf_netd_shared yes, T+ network_stack & system_server & netd [**]
/tethering fs_bpf_tethering yes, S+ network_stack
/vendor fs_bpf_vendor no, T+ vendor
* initial support for bpf was added back in P,
but things worked differently back then with no bpfloader,
and instead netd doing stuff by hand,
bpfloader with pinning into /sys/fs/bpf was (I believe) added in Q
(and was definitely there in R)
** additionally bpf programs are accesible to netutils_wrapper
for use by iptables xt_bpf extensions
'mainline yes' currently means shipped by the com.android.tethering apex,
but this is really another case of bad naming, as it's really
the 'networking/connectivity/tethering' apex / mainline module.
Long term the plan is to merge a few other networking mainline modules
into it (and maybe give it a saner name...).
The reason for splitting net_private vs tethering is that:
S+ must support 4.9+ kernels and S era bpfloader v0.2+
T+ must support 4.14+ kernels and T beta3 era bpfloader v0.13+
The kernel affects the intelligence of the in-kernel bpf verifier
and the available bpf helper functions. Older kernels have
a tendency to reject programs that newer kernels allow.
/ && /vendor are not shipped via mainline, so only need to work
with the bpfloader that's part of the core os.
Bug: 218408035
Test: TreeHugger, manually on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I674866ebe32aca4fc851818c1ffcbec12ac4f7d4
(cherry picked from commit 15715aea32)
This is required for testing new ethernet APIs in T.
This change is not identical to the corresponding AOSP change
because it also needs to update the T prebuilts.
Test: TH
Bug: 171872016
(cherry picked from commit 02b55354bd)
(cherry picked from commit 69fa8ca6f2)
Change-Id: I036e48530e37f7213a21b250b858a37fba3e663b
This change enables xfrm netlink socket use for the system server,
and the network_stack process. This will be used by IpSecService
to configure SAs, and network stack to monitor counters & replay
bitmaps for monitoring of IPsec tunnels.
This patch updates the prebuilts, in addition to the changes to the
master source.
Bug: 233392908
Test: Compiled
(cherry picked from commit b25b4bf53f)
(cherry picked from commit 8b7c1cbd5e)
Change-Id: I55e03a3ca7793b09688f603c973c38bd2f6e7c7f
Give system_server and network_stack the same permissions as netd.
This is needed as we are continuously moving code out of netd into
network_stack and system_server.
This change is not identical to the corresponding AOSP change
because it also needs to update the T prebuilts.
Test: TH
Bug: 233300834
(cherry picked from commit ab02397814)
(cherry picked from commit d0478822ce)
Change-Id: Ic98c6fc631ee98bef4b5451b6b52d94e673b4f3c
Goal is to gain a better handle on who has access to which maps
and to allow (with bpfloader changes to create in one directory
and move into the target directory) per-map selection of
selinux context, while still having reasonable defaults for stuff
pinned directly into the target location.
BPFFS (ie. /sys/fs/bpf) labelling is as follows:
subdirectory selinux context mainline usecase / usable by
/ fs_bpf no (*) core operating system (ie. platform)
/net_private fs_bpf_net_private yes, T+ network_stack
/net_shared fs_bpf_net_shared yes, T+ network_stack & system_server
/netd_readonly fs_bpf_netd_readonly yes, T+ network_stack & system_server & r/o to netd
/netd_shared fs_bpf_netd_shared yes, T+ network_stack & system_server & netd [**]
/tethering fs_bpf_tethering yes, S+ network_stack
/vendor fs_bpf_vendor no, T+ vendor
* initial support for bpf was added back in P,
but things worked differently back then with no bpfloader,
and instead netd doing stuff by hand,
bpfloader with pinning into /sys/fs/bpf was (I believe) added in Q
(and was definitely there in R)
** additionally bpf programs are accesible to netutils_wrapper
for use by iptables xt_bpf extensions
'mainline yes' currently means shipped by the com.android.tethering apex,
but this is really another case of bad naming, as it's really
the 'networking/connectivity/tethering' apex / mainline module.
Long term the plan is to merge a few other networking mainline modules
into it (and maybe give it a saner name...).
The reason for splitting net_private vs tethering is that:
S+ must support 4.9+ kernels and S era bpfloader v0.2+
T+ must support 4.14+ kernels and T beta3 era bpfloader v0.13+
The kernel affects the intelligence of the in-kernel bpf verifier
and the available bpf helper functions. Older kernels have
a tendency to reject programs that newer kernels allow.
/ && /vendor are not shipped via mainline, so only need to work
with the bpfloader that's part of the core os.
Ignore-AOSP-First: will be cherrypicked from tm-dev to aosp/master
Bug: 218408035
Test: TreeHugger, manually on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I674866ebe32aca4fc851818c1ffcbec12ac4f7d4
