(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
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)
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
Previously I've resisted granting write access to these files, since
it allows the instance image to be altered. But that doesn't allow an
attacker to do anything other than render it invalid, since it's
protected by the VM key.
Note that logs are only written when the VM is debuggable, which is
currently only when only non-protected VMs are available.
Bug: 235350758
Test: Force debug on, stage APEX, compile, reboot -> see vm logs
Test: Presubmit
Change-Id: I17c9a17db83d15adfab97b8cfe4ccd67393a08c1
This change allows remote_prov_app to find mediametrics. This is a
permission that all apps have. It is now needed for remote_prov_app due
to a new feature related to provisioning Widevine through the MediaDrm
framework.
Bug: 235491155
Test: no selinux denials related to remote_prov_app
Change-Id: Id3057b036486288358a9a84100fe808eb56df5fe
Merged-In: Id3057b036486288358a9a84100fe808eb56df5fe
These will get read by system libraries in arbitrary processes, so it's
a public property with read access by `domain`.
Bug: 235129567
Change-Id: I1ab880626e4efa2affe90165ce94a404b918849d
Init attempts to rm -rf these files, to ensure any that are owned by
the old virtualizationservice UID get deleted. This fails for newer
directories, now we use the system UID, which is harmless. But rm
attempts to chmod the directories since it can't read them, which also
fails and generates a spurious audit. So here we suppress that.
Bug: 235338094
Test: No denials seen even when there are stale directories present
Change-Id: If55fbe151174ee08a12b64b301e4aa86ffc1a5bf
This change allows remote_prov_app to find mediametrics. This is a
permission that all apps have. It is now needed for remote_prov_app due
to a new feature related to provisioning Widevine through the MediaDrm
framework.
Ignore-AOSP-First: Need to cherry pick to TM-dev
Bug: 235491155
Test: no selinux denials related to remote_prov_app
Change-Id: Id3057b036486288358a9a84100fe808eb56df5fe
The feature was superseded by tzdata mainline module(s).
Bug: 148144561
Test: see system/timezone
Test: m selinux_policy
Change-Id: I48d445ac723ae310b8a134371342fc4c0d202300
Merged-In: I48d445ac723ae310b8a134371342fc4c0d202300
Remove mention of the /system/bin/idmap binary: the file no longer
exists.
Remove interaction between the domains installd and idmap to interact:
installd used to fork and exec the idmap binary, but the idmap2 binary
has its own binder service.
Bug: 118711077
Bug: 119264713
Test: atest FrameworksServicesTests:com.android.server.om OverlayDeviceTests OverlayHostTests CtsAppSecurityHostTestCases:OverlayHostTest
Change-Id: I06d22057308984e43cb84ff365dbdd1864c7064b
It was default_prop. Label it build_prop for good code hygiene.
Bug: 223517900
Test: Boot with and without debug boot image
Change-Id: I4e00d301eb526a0fc9e29657cbcedda8dd0fc7b1
