Ideally, public should only contain APIs (types / attributes) for
vendor. The other statements like allow/neverallow/typeattributes are
regarded as implementation detail for platform and should be in private.
Bug: 232023812
Test: m selinux_policy
Test: diff <(git diff --staged | grep "^-" | cut -b2- | sort) \
<(git diff --staged | grep "^+" | cut -b2- | sort)
Test: remove comments on plat_sepolicy.cil, replace base_typeattr_*
to base_typeattr and then compare old and new plat_sepolicy.cil
Change-Id: I5e7d2da4465ab0216de6bacdf03077d37f6ffe12
This is needed to allow vendor xt_bpf programs.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7ff8a0319bec2f3a57c7ce48939b13b2fca182de
This is so that we can potentially verify that things
are setup right.
Test: TreeHugger
Bug: 275209284
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I59a49cbece2710345fff0b2fb98e32f4e5f3af44
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)
Require all domains which can be used for BPF to be marked as
bpfdomain, and add a restriction for these domains to not
be able to use net_raw or net_admin. We want to make sure the
network stack has exclusive access to certain BPF attach
points.
Bug: 140330870
Bug: 162057235
Test: build (compile-time neverallows)
Change-Id: I29100e48a757fdcf600931d5eb42988101275325
mdns service is a subset of netd-provided services, so it gets
the same treatment as netd_service or dnsresolver_service
Bug: 209894875
Test: built, flashed, booted
Change-Id: I33de769c4fff41e816792a34015a70f89e4b8a8c
Addresses spurious denials caused by users of netutils_wrapper which
open files in /sys without O_CLOEXEC.
avc: denied { read } for comm="iptables-wrappe"
dev="sysfs" ino=47786 scontext=u:r:netutils_wrapper:s0
tcontext=u:object_r:sysfs_msm_subsys:s0 tclass=file
Test: build
Change-Id: I1c1f82428555be6a9798a189420dd85a9db107f7
Files in /proc/net leak information. This change is the first step in
determining which files apps may use, whitelisting benign access, and
otherwise removing access while providing safe alternative APIs.
To that end, this change:
* Introduces the proc_net_type attribute which will assigned to any
new SELinux types in /proc/net to avoid removing access to privileged
processes. These processes may be evaluated later, but are lower
priority than apps.
* Labels /proc/net/{tcp,tcp6,udp,udp6} as proc_net_vpn due to existing
use by VPN apps. This may be replaced by an alternative API.
* Audits all other proc/net access for apps.
* Audits proc/net access for other processes which are currently
granted broad read access to /proc/net but should not be including
storaged, zygote, clatd, logd, preopt2cachename and vold.
Bug: 9496886
Bug: 68016944
Test: Boot Taimen-userdebug. On both wifi and cellular: stream youtube
navigate maps, send text message, make voice call, make video call.
Verify no avc "granted" messages in the logs.
Test: A few VPN apps including "VPN Monster", "Turbo VPN", and
"Freighter". Verify no logspam with the current setup.
Test: atest CtsNativeNetTestCases
Test: atest netd_integration_test
Test: atest QtaguidPermissionTest
Test: atest FileSystemPermissionTest
Change-Id: I7e49f796a25cf68bc698c6c9206e24af3ae11457
Merged-In: I7e49f796a25cf68bc698c6c9206e24af3ae11457
(cherry picked from commit 087318957f)
The netutils_wrapper is a process used by vendor code to update the
iptable rules on devices. When it update the rules for a specific chain.
The iptable module will reload the whole chain with the new rule. So
even the netutils_wrapper do not need to add any rules related to xt_bpf
module, it will still reloading the existing iptables rules about xt_bpf
module and need pass through the selinux check again when the rules are
reloading. So we have to grant it the permission to reuse the pinned
program in fs_bpf when it modifies the corresponding iptables chain so
the vendor module will not crash anymore.
Test: device boot and no more denials from netutils_wrapper
Bug: 72111305
Change-Id: I62bdfd922c8194c61b13e2855839aee3f1e349be
In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.
This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.
This is essentially:
1. New global_capability_class_set and global_capability2_class_set
that match capability+cap_userns and capability2+cap2_userns,
respectively.
2. s/self:capability/self:global_capability_class_set/g
3. s/self:capability2/self:global_capability2_class_set/g
4. Add cap_userns and cap2_userns to the existing capability_class_set
so that it covers all capabilities. This set was used by several
neverallow and dontaudit rules, and I confirmed that the new
classes are still appropriate.
Test: diff new policy against old and confirm that all new rules add
only cap_userns or cap2_userns;
Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831
Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f
Bug: 36463595
Test: Boot sailfish, make wifi call, internet over data and wifi
Change-Id: I81259b6412d7197725afe2fe4976aa0a03b8df6e
Signed-off-by: Sandeep Patil <sspatil@google.com>
