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