Hacker News new | ask | show | jobs
by ranger_danger 26 days 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.
1 comments
fc417fc802 26 days ago
You 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.)

link
ranger_danger 25 days 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.

link
fc417fc802 25 days ago
By 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?

link
ranger_danger 25 days ago
My 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.
link