3 ms·
One possible mitigation might be to run your system (or just the browser/certain apps) sandboxed to only communicate with the IP/ports mullvad uses for VPNs.
by ranger_danger 5mo ago
One possible mitigation might be to run your system (or just the browser/certain apps) sandboxed to only communicate with the IP/ports mullvad uses for VPNs.
- fc417fc802 5mo agoYou absolutely shouldn't do that because a vulnerability in the kernel can be immediately escalated into decloaking your real IP. /s (TBF this is presumably why parent specified that proxying ought to happen on separate hardware.)
- ranger_danger 5mo ago> a vulnerability in the kernel can be immediately escalated into decloaking your real IP Not necessarily IMO... if you create a network namespace that can only communicate with mullvad, and then run the VM inside that... even owning the entire VM and escaping it doesn't help you... you would now have to exploit the host kernel as well, which to me is basically just as good as it being separate hardware in the first place.
- fc417fc802 5mo agoBy the time someone has pulled off a VM escape I think it's safe to assume they're akin to a state level actor and a network namespace isn't going to stop them. That said, did you perhaps miss the /s tag?
- ranger_danger 5mo agoMy threat model does not include state level actors, I don't think it's feasible for people to adequately protect themselves from most of them.