Comment 12 for bug 1480979
Revision history for this message
| Andreas Scheuring (andreas-scheuring) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Seems like I got some clarification. Would be great if you could asses my assumptions:
Libvirt offers a option trustGuestRxFilters
- Having it set to no (default)
The guest can set another mac address on it's interface and send out packets with this mac. But a reply will never come back to the guest, as the macvtap does not consider this mac in it's mac filter (or however this is implemented). So we could say, that there is some very lightweight mac spoofing prevention. However the attacker in the guest can confuse the switches outside with this potential duplicated mac which is of course problematic.
And the problem with this approach is, that the guest cannot use multicast (which would require access to the Rx filters to figure out the multicast mac addresses)!
- Having it set to yes
All guest mac addresses will be added to the macvtaps mac filter (including multicast macs). But the door is totally open for arp spoofing.
So I agree, we should state that there is only this very restricted security feature.
Does that make sense?
Regarding promisc. mode, the argumentation is that with macvtap you do not need promisc mode at all, as the macs get registered.
Thank you!
[1] http://