On 12.6.2020 1.19, Paul Moore wrote:
On Tue, Jun 9, 2020 at 10:05 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
On Tue, Jun 9, 2020 at 4:39 AM Topi Miettinen <toiwoton@xxxxxxxxx> 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
