On 15.6.2020 0.30, Topi Miettinen wrote:
On 12.6.2020 12.21, Topi Miettinen wrote:
Perhaps instead this would work (I haven't tested it yet): don't use
netifs or nodes for anything (label everything with generic types
netif_t and node_t, which is actually the reference policy) but
instead use netlabel tools to label peers according to interfaces and
IP subnets.
The problem here is that flow outwards is not restricted by peer rules.
The rules below don't prevent ping_t from sending packets to the local
network, only from receiving the responses:
type localnet_peer_t;
allow ping_t localnet_peer_t:peer recv;
The peer was labeled like this:
# netlabelctl unlbl add interface:wlan0 address:10.0.0.0/8
label:system_u:object_r:localnet_peer_t:s0
To stop sending, also nodes and/or netifs need to be used, for example:
type external_if_t, netif_type;
type localnet_node_t, node_type;
allow ping_t external_if_t:netif egress;
allow ping_t localnet_node_t:node sendto;
# semanage interface -a -t external_if_t -r s0 wlan0
# semanage node -a -t localnet_node_t -p ipv4 -M /8 10.0.0.0
It would be most flexible if peers could be used to restrict outward
flow too (since semanage interface & node are slow and require writable
policy). Would this be possible?
It would seem to need a small change around
security/selinux/hooks.c:5801 to add a check matching
security/selinux/hooks.c:5024 but with PEER__SEND (which does not exist,
so this would actually become a much bigger change). Would such a patch
be acceptable? How should compatibility to earlier versions be handled,
with policycaps maybe?
This would let me use rules like
allow ping_t localnet_peer_t:peer { recv send };
without node or netif rules and netlabelctl could be used to manage
dynamic interfaces.
-Topi
