On Sun, Jun 14, 2020 at 5:30 PM Topi Miettinen <toiwoton@xxxxxxxxx> 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 If you are using secmark, you also have the following access control check: allow ping_t secmark_t:packet send; ... for locally generated traffic. The combination of the peer label and the secmark label is particularly powerful. > 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? Not in a general sense since you don't reliably know the destination's peer label. If it is a stream based connection you could make a solid guess, but that might not always be correct if the remote peer is running with multiple labels/levels. -- paul moore www.paul-moore.com
