Re: Better management of dynamic networks?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15.6.2020 23.33, Stephen Smalley wrote:
On Mon, Jun 15, 2020 at 4:26 PM Topi Miettinen <toiwoton@xxxxxxxxx> wrote:

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.

This seems more along the lines of what SECMARK is for, along with the
PACKET__SEND check.

SECMARK gives the ability to limit sending packets to ports but if sending is allowed, all destinations are possible. Maybe the Netfilter rules could label packets differently based on the destination (or source) addresses, at the expense of N_packet_types * N_destination_classes rules but this would not be compatible with reference policy. Perhaps this could be optimized for simple cases, so that localhost ports use refpolicy labels and only the external access ports (which should be few) are renamed. I think PEER__SEND would be simpler.

-Topi



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux