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? 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).
