pull down to refresh
Knowing there's a design where the node can be fully compromised and still only get to ask "will you sign this?" is a good reason to sleep better as a bitcoiner.
Thanks for the AMA, for the answers, and above all, for building ⚡🔨
You're welcome. You can always choose how you deploy the software. For instance, even if you are constrained and can only use a single device for both the node software and VLS, you can also use any Unixlike OS and have separate users for the node software and VLS. Then even if the attacker can shellcode your node software, it still cannot access the VLS userspace, as it is a different user. Of course, if the node software is rootkitted, it can now access everything, which is why we still recommend separate devices, but it is still a (smaller) security improvement to have VLS on the same machine but under a separate user.
the policy setup is on the VLS machine itself as part of the VLS configuration, and there is also a VLS command interface that lets you tweak some policies (like e.g. adding addresses to the allowed-to-be-sent-to list). Assuming your VLS machine is not compromised (it can be hardened, e.g. by firewalls that disallow all incoming connections since VLS itself makes an OUTgoing connection to the node) then the node cannot change the VLS policy.
Now, in theory, the VLS software can be compromised by some protocol shenanigans with the node software itself (e.g. some parsing error in the node<->VLS protocol might lead to a buffer overrun?), but now you are compromising both the node software and VLS, which is something of a failure mode we really cannot protect against; our security argument is that compromising the node software (which generally needs to be allowed to accept incoming BOLT8 connections, and has to handle stuff like gossip maps and routing) is a lot easier than compromising the VLS machine (which as noted can be hardened by disallowing all incoming connections)