All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <karl@bigbadwolfsecurity.com>
To: SElinux list <selinux@vger.kernel.org>, Paul Moore <paul@paul-moore.com>
Subject: KVM / virtual networking access control
Date: Fri, 29 Jul 2022 23:36:05 -0400	[thread overview]
Message-ID: <CA+EEuAgfGhTWBWXgtHSVU22feM+0PS=h-z-eVF4JxmSf2qyZzg@mail.gmail.com> (raw)

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 };

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

I can see that the packet send / recv LSM hook is in netfilter
postrouting code, but I simply cannot trigger this with the setup that
I have. Here are things that I have tried:

1. br_netfilter - I thought initially that my problem was that the
traffic was at layer 2 and was not traversing the netfilter hooks.
This was, in fact, a problem with my initial setup (both VMs on the
same subnet) and br_netfilter got traffic to hit netfilter hooks. But
no matter what hook I chose, the best I could get was forward_in /
forward_out.

2. various traffic selectors - I've used mac address, ip address, and
physical interface (all of the different interfaces) to set the
secmark labels.

3. ebtables - secmark support seems totally broken in ebtables, both
what is in RHEL 8.6 and upstream. It's in the options parsing.

4. nftables - to work around ebtables I used nftables bridge family to
label layer 2 traffic. None of the hooks would yield anything other
than forward_in / forward_out.

5. routing - I placed the VMs on separate subnets and added multiple
addresses to the bridge. My thought was that forcing the traffic to
route would push it up to layer 3 and would make it hit the
postrouting hook (this may be a completely broken mental model of
things).

You can see how I'm doing this with some very rough / poorly
documented scripts at
https://github.com/BigBadWolfSecurity/kvm-access-control. VMs are
created / managed through libvirt / virt-manager.

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.

Thanks - Karl

             reply	other threads:[~2022-07-30  3:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-30  3:36 Karl MacMillan [this message]
2022-07-31 16:45 ` KVM / virtual networking access control Paul Moore
2022-08-09 18:45   ` Karl MacMillan
2022-08-10 22:04     ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+EEuAgfGhTWBWXgtHSVU22feM+0PS=h-z-eVF4JxmSf2qyZzg@mail.gmail.com' \
    --to=karl@bigbadwolfsecurity.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.