4 ms·
>This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely. I don't know how VPNs are implemented on
by PhilipRoman 3y ago
>This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely.
I don't know how VPNs are implemented on Linux, but in principle it should be possible to sandbox a VPN server to the point where it can only make connections but nothing else. If capabilities are not enough, ebpf should be able to contain it. I suspect it will have full control over networking but that's still very different from arbitrary code execution.
- teddyh 3y agoThat would be possible, yes, but it’s not the current situation. And since we can choose how we proceed, I would prefer my proposal, i.e. that the SSH daemon be split into two separate projects, one daemon handling the initial connection, locked-down like you describe, then handing off the authenticated connection to the second, “inner”, SSH daemon, which also does the authentication, using the same credentials as submitted by the connecting user. This way, the connecting user only has to have one key, and the network topology does not become unduly twisted.
- PhilipRoman 3y agoHuh, I briefly looked at the documentation for UsePrivilegeSeparation option and it looks very similar to what you're describing. Interesting why it didn't prevent this attack.
- teddyh 3y agoNote that UsePrivilegeSeparation is no longer an option; it is mandatory since OpenSSH 7.5, released seven years ago.