On Fri, Jul 29, 2022 at 11:36 PM Karl MacMillan
<karl@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> I'm trying to do some access control over the networking between KVM
> virtual machines using Secmark and things are not working as I expect.
> The key is that this is _between_ virtual machines, not just ingress /
> egress to the virtual machines from external address.
>
> Quick summary: I'm connecting two VMs together using veth pairs and a
> virtual bridge and I only ever see:
>
> allow unlabeled_t bare_packet_a_t:packet { forward_in forward_out };
Just to make sure I'm understanding this correctly, we are talking
about the SELinux controls from the perspective of the
host/hypervisor, yes?
Assuming that is the case, the "packet/{ forward_in forward_out }"
permissions look correct to me. In the case of the secmark forwarding
rules you basically have this:
allow <peer> <secmark>:packet { forward_in };
allow <peer> <secmark>:packet { forward_out };
... and I'm guessing you haven't setup any peer labeling between the
two guests so you are seeing unlabeled_t for "<peer>".
> What I want is packet { send recv } because that would be against the
> label of the KVM process rather than the peer label (which on the same
> system would always be unlabeled - I see no way to use CIPSO/CALIPSO
> to get peer labels to work here).
The "packet/{ send recv }" controls are for packets that originate and
terminate on the node applying the policy; think of your typical
client/server nodes. The "packet/{ forward_in forward_out }" controls
are for packets that are passing through the node applying the policy,
e.g. intermediate nodes such as bridges and switches ... even software
bridges like that found in hypervisors ;)
> I would appreciate any insight into what might be going on. This is
> mainly tested on a RHEL 8.6 box, but some testing has been done on a
> Fedora 36 box as well.
I don't know all the details of your setup, or the security goals you
are trying to enforce, but since it looks like you are bridging the
network traffic between the guests, you might want to try setting up
the NetLabel static/fallback mechanism to assign a peer label to
traffic on those interfaces (no more unlabeled_t in the secmark
forwarding rules). Adding the peer labeling information will also
trigger the network peer label controls in the kernel so you will see
additional "netif/{ ingress egress}" and "node/{ recvfrom sendto }"
checks.
Here are few slides that might be helpful (they are older, but still relevant):
https://www.paul-moore.com/docs/selinux_network_controls-pmoore-122012-r1.pdf
https://www.paul-moore.com/docs/labeled_networking-lfjapan-07092008.pdf
--
paul-moore.com
