Better management of dynamic networks?

Better management of dynamic networks?

[Topi Miettinen]

Hi,

I have a SELinux setup for networks, where packets, nodes, interfaces 
and peers are labeled and subject to TE rules. In general the system 
works very well and I'm thankful to be able to control network access 
for each individual application in great detail.

I'm still learning SELinux, so maybe I have missed something, but it 
seems to me that these systems have been designed with rather static 
network configuration in mind. For example, I have classified IPv4 and 
most of IPv6 addresses to loopback, localnet (e.g. 10.0.0.0/8), 
multicast and "internet" node types. This can be used with a fixed set 
of TE rules. But when using a laptop, actually the rules for local 
network should depend on whether I'm at home, at a friend's place or 
some random public network and then there are VPNs.

The interfaces and peers are labeled with netlabelctl, but the 
interfaces change when kernel modules are loaded and removed for 
interfaces and it's also possible to plug in a USB network adapter any 
time. With Netlabel it's possible to label peers without modifying the 
policy (for example during boot), but `semanage node` and `semanage 
interface` require writable policy. Netlabelctl can't label an interface 
if the interface does not exist yet, but I've opened a PR for a possible 
workaround.

The tools don't support for example pattern matching for interfaces. It 
would be nice to assign SELinux labels based on various properties of 
the interface and network, for example with udevd, systemd-networkd or 
NetworkManager, without requiring policy rebuild.

A minor issue is that reference policy also has rules which allow 
network access when using the default initial types (netif_t, node_t). 
It could be preferrable that new network interfaces would not get labels 
which allow access. In my case I've tried to make sure that the initial 
types are never used. Perhaps the related rules could simply be made 
optional.

I suppose using CIPSO/CALIPSO/Labeled IPsec can solve some of these 
issues when you can positively identify the other parties in a network, 
but they are not fit for general Internet access or when the network is 
friendly but not under your control.

So, what could be done to lift these restrictions (if they really exist 
and I haven't missed something obvious)?

-Topi

Re: Better management of dynamic networks?

[Paul Moore]

On Sat, Jun 6, 2020 at 8:27 AM Topi Miettinen <toiwoton@gmail.com> wrote:
> Hi,
>
> I have a SELinux setup for networks, where packets, nodes, interfaces
> and peers are labeled and subject to TE rules. In general the system
> works very well and I'm thankful to be able to control network access
> for each individual application in great detail.
>
> I'm still learning SELinux, so maybe I have missed something, but it
> seems to me that these systems have been designed with rather static
> network configuration in mind ...

Yes, historically the SELinux users who cared about labeled networking
have typically had a stable network configuration.  Or at the very
least they haven't discussed problems with a dynamic network
configuration.

> The interfaces and peers are labeled with netlabelctl, but the
> interfaces change when kernel modules are loaded and removed for
> interfaces and it's also possible to plug in a USB network adapter any
> time. With Netlabel it's possible to label peers without modifying the
> policy (for example during boot), but `semanage node` and `semanage
> interface` require writable policy. Netlabelctl can't label an interface
> if the interface does not exist yet, but I've opened a PR for a possible
> workaround.
>
> The tools don't support for example pattern matching for interfaces. It
> would be nice to assign SELinux labels based on various properties of
> the interface and network, for example with udevd, systemd-networkd or
> NetworkManager, without requiring policy rebuild.

I can't say I'm an expert on all the various userspace device
managers, network or otherwise, but so long as they can execute an
arbitrary command then one should be able to use them to label the
device when it is added to the system.  Although perhaps we could make
this easier with docs and/or tools.

I would be curious to hear what the SELinux userspace folks think about this.

-- 
paul moore
www.paul-moore.com

Re: Better management of dynamic networks?

[Topi Miettinen]

On 9.6.2020 0.16, Paul Moore wrote:
> I can't say I'm an expert on all the various userspace device
> managers, network or otherwise, but so long as they can execute an
> arbitrary command then one should be able to use them to label the
> device when it is added to the system.  Although perhaps we could make
> this easier with docs and/or tools.

Perhaps this could be solved at least partially by adding a layer of 
indirection. So instead of directly assigning TE rules to interfaces, 
nodes and peers, the rules could apply to type attributes (or something 
else). Then the interfaces, nodes and peers would be tagged somehow with 
suitable attributes. Preferably tagging should be a faster operation 
than rebuilding the policy, but the operation should still be controlled 
by policy.

So, instead of assigning for example localnet_node_t directly to subnets 
(which may have different levels of trust depending on the location) 
with commands (which rebuild the policy) like:

semanage node -a -t localnet_node_t -p ipv4 -M /8 10.0.0.0

there would be a static TE rule which states that networks with type 
(attribute?) 'trusted_localnet' get the label localnet_node_t. Then 
something else (what, how?) would assign the address ranges with the 
attributes when the network configuration (like interface up/down 
status, SSID, routing tables...) changes.

Likewise, instead of direct assignment like
semanage interface -a -t external_if_t -r s0 wlan0

there would be static TE rules which state that only interfaces with 
type attributes 'company_approved_model', 'not_random_usb_device', 
'company_authenticated_vpn' can get the label external_if_t. Then when 
new interfaces appear, something else (udevd? how?) would tag the 
interfaces with the attributes.

Would this solve anything?

-Topi

Re: Better management of dynamic networks?

[Stephen Smalley]

On Tue, Jun 9, 2020 at 4:39 AM Topi Miettinen <toiwoton@gmail.com> wrote:
>
> On 9.6.2020 0.16, Paul Moore wrote:
> > I can't say I'm an expert on all the various userspace device
> > managers, network or otherwise, but so long as they can execute an
> > arbitrary command then one should be able to use them to label the
> > device when it is added to the system.  Although perhaps we could make
> > this easier with docs and/or tools.
>
> Perhaps this could be solved at least partially by adding a layer of
> indirection. So instead of directly assigning TE rules to interfaces,
> nodes and peers, the rules could apply to type attributes (or something
> else). Then the interfaces, nodes and peers would be tagged somehow with
> suitable attributes. Preferably tagging should be a faster operation
> than rebuilding the policy, but the operation should still be controlled
> by policy.
>
> So, instead of assigning for example localnet_node_t directly to subnets
> (which may have different levels of trust depending on the location)
> with commands (which rebuild the policy) like:
>
> semanage node -a -t localnet_node_t -p ipv4 -M /8 10.0.0.0
>
> there would be a static TE rule which states that networks with type
> (attribute?) 'trusted_localnet' get the label localnet_node_t. Then
> something else (what, how?) would assign the address ranges with the
> attributes when the network configuration (like interface up/down
> status, SSID, routing tables...) changes.
>
> Likewise, instead of direct assignment like
> semanage interface -a -t external_if_t -r s0 wlan0
>
> there would be static TE rules which state that only interfaces with
> type attributes 'company_approved_model', 'not_random_usb_device',
> 'company_authenticated_vpn' can get the label external_if_t. Then when
> new interfaces appear, something else (udevd? how?) would tag the
> interfaces with the attributes.
>
> Would this solve anything?

The kernel doesn't label objects with attributes; it labels them with types.
Attributes are only used within rules (and originally they didn't even
exist in the kernel policy; they were entirely expanded by the policy
compilation process, first as a preprocessor stage and later directly
in checkpolicy/libsepol).

Re: Better management of dynamic networks?

[Paul Moore]

On Tue, Jun 9, 2020 at 10:05 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Tue, Jun 9, 2020 at 4:39 AM Topi Miettinen <toiwoton@gmail.com> wrote:
> > On 9.6.2020 0.16, Paul Moore wrote:
> > > I can't say I'm an expert on all the various userspace device
> > > managers, network or otherwise, but so long as they can execute an
> > > arbitrary command then one should be able to use them to label the
> > > device when it is added to the system.  Although perhaps we could make
> > > this easier with docs and/or tools.
> >
> > Perhaps this could be solved at least partially by adding a layer of
> > indirection. So instead of directly assigning TE rules to interfaces,
> > nodes and peers, the rules could apply to type attributes (or something
> > else). Then the interfaces, nodes and peers would be tagged somehow with
> > suitable attributes. Preferably tagging should be a faster operation
> > than rebuilding the policy, but the operation should still be controlled
> > by policy.
> >
> > So, instead of assigning for example localnet_node_t directly to subnets
> > (which may have different levels of trust depending on the location)
> > with commands (which rebuild the policy) like:
> >
> > semanage node -a -t localnet_node_t -p ipv4 -M /8 10.0.0.0
> >
> > there would be a static TE rule which states that networks with type
> > (attribute?) 'trusted_localnet' get the label localnet_node_t. Then
> > something else (what, how?) would assign the address ranges with the
> > attributes when the network configuration (like interface up/down
> > status, SSID, routing tables...) changes.
> >
> > Likewise, instead of direct assignment like
> > semanage interface -a -t external_if_t -r s0 wlan0
> >
> > there would be static TE rules which state that only interfaces with
> > type attributes 'company_approved_model', 'not_random_usb_device',
> > 'company_authenticated_vpn' can get the label external_if_t. Then when
> > new interfaces appear, something else (udevd? how?) would tag the
> > interfaces with the attributes.
> >
> > Would this solve anything?

I'm still not entirely sure this really solves the problem, it just
changes it slightly.  You would now need to worry about making sure
you have the right types defined in the policy, and I'm not sure we
can generalize the world's network configurations into a reasonable
set of types.  Not to mention the problem of mapping the
subnets/interfaces to those types.

> The kernel doesn't label objects with attributes; it labels them with types.
> Attributes are only used within rules (and originally they didn't even
> exist in the kernel policy; they were entirely expanded by the policy
> compilation process, first as a preprocessor stage and later directly
> in checkpolicy/libsepol).

-- 
paul moore
www.paul-moore.com

Re: Better management of dynamic networks?

[Topi Miettinen]

On 12.6.2020 1.19, Paul Moore wrote:
> On Tue, Jun 9, 2020 at 10:05 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>> On Tue, Jun 9, 2020 at 4:39 AM Topi Miettinen <toiwoton@gmail.com> wrote:
>>> On 9.6.2020 0.16, Paul Moore wrote:
>>>> I can't say I'm an expert on all the various userspace device
>>>> managers, network or otherwise, but so long as they can execute an
>>>> arbitrary command then one should be able to use them to label the
>>>> device when it is added to the system.  Although perhaps we could make
>>>> this easier with docs and/or tools.
>>>
>>> Perhaps this could be solved at least partially by adding a layer of
>>> indirection. So instead of directly assigning TE rules to interfaces,
>>> nodes and peers, the rules could apply to type attributes (or something
>>> else). Then the interfaces, nodes and peers would be tagged somehow with
>>> suitable attributes. Preferably tagging should be a faster operation
>>> than rebuilding the policy, but the operation should still be controlled
>>> by policy.
>>>
>>> So, instead of assigning for example localnet_node_t directly to subnets
>>> (which may have different levels of trust depending on the location)
>>> with commands (which rebuild the policy) like:
>>>
>>> semanage node -a -t localnet_node_t -p ipv4 -M /8 10.0.0.0
>>>
>>> there would be a static TE rule which states that networks with type
>>> (attribute?) 'trusted_localnet' get the label localnet_node_t. Then
>>> something else (what, how?) would assign the address ranges with the
>>> attributes when the network configuration (like interface up/down
>>> status, SSID, routing tables...) changes.
>>>
>>> Likewise, instead of direct assignment like
>>> semanage interface -a -t external_if_t -r s0 wlan0
>>>
>>> there would be static TE rules which state that only interfaces with
>>> type attributes 'company_approved_model', 'not_random_usb_device',
>>> 'company_authenticated_vpn' can get the label external_if_t. Then when
>>> new interfaces appear, something else (udevd? how?) would tag the
>>> interfaces with the attributes.
>>>
>>> Would this solve anything?
> 
> I'm still not entirely sure this really solves the problem, it just
> changes it slightly.  You would now need to worry about making sure
> you have the right types defined in the policy, and I'm not sure we
> can generalize the world's network configurations into a reasonable
> set of types.  Not to mention the problem of mapping the
> subnets/interfaces to those types.

Yes, probably the network rules can't be generic enough to cover every case.

>> The kernel doesn't label objects with attributes; it labels them with types.
>> Attributes are only used within rules (and originally they didn't even
>> exist in the kernel policy; they were entirely expanded by the policy
>> compilation process, first as a preprocessor stage and later directly
>> in checkpolicy/libsepol).

OK, let's forget this idea.

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. Then udevd etc. would invoke netlabel-config (or something 
similar) when network configuration changes. This would not require any 
changes to kernel, SELinux userspace except for netlabel tools, nor 
reference policy. The policy can be also read-only. Also, if it is 
determined that the IPSec etc. should be used in the local network, 
netlabel tools are needed to manage the case anyway.

-Topi

Re: Better management of dynamic networks?

[Topi Miettinen]

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?

-Topi

Re: Better management of dynamic networks?

[Topi Miettinen]

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

Re: Better management of dynamic networks?

[Stephen Smalley]

On Mon, Jun 15, 2020 at 4:26 PM Topi Miettinen <toiwoton@gmail.com> 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.

Re: Better management of dynamic networks?

[Topi Miettinen]

On 15.6.2020 23.33, Stephen Smalley wrote:
> On Mon, Jun 15, 2020 at 4:26 PM Topi Miettinen <toiwoton@gmail.com> 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

Re: Better management of dynamic networks?

[Paul Moore]

On Sun, Jun 14, 2020 at 5:30 PM Topi Miettinen <toiwoton@gmail.com> 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