3 ms·
> In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other. So your "trust
by zvrba 9y ago
> In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other.
So your "trusted" components now incorporate a TCP/IP or another network stack. Plus you'll somehow have to authenticate the other end...
- lmm 9y agoThe network stack shouldn't need to be trusted - inter-unikernel routing can be done by another (untrusted) dedicated unikernel, just as in a microkernel. And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point.
- zvrba 9y ago> inter-unikernel routing can be done by another (untrusted) dedicated unikernel If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? > And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point. So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing?
- lmm 9y ago> If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? If an attacker compromises it the worst they can do is block messages causing a DoS. > So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing? Yes except that with that approach you still have all the other ways those processes could interfere with each other.
- zvrba 9y ago> Yes except that with that approach you still have all the other ways those processes could interfere with each other. Yes, you're right, add to that seccomp: http://man7.org/linux/man-pages/man2/seccomp.2.html http://man7.org/linux/man-pages/man2/seccomp.2.html