Hacker News Reader

Comment by ec109685 | Hacker News Reader

What attack scenarios you are envisioning here? If the host is only running this software (e.g. a single purpose server, firewall, etc.), the security benefits of process isolation are reduced.

Clearly if you are trying to run hostile software from multiple vendors on the same box (e.g. a browser), you want more sandboxes.

View on HN

I see a future where the npm-style ecosystem develops with the JIT running inside the kernel, so you end up running a "trusted" application ends up running a whole lot of untrusted code via dependencies. Usually process isolation gives you some limit on how much damage something like that can do.

Also, if you are 100% sure that the code in it is trusted, then there really is no reason to sandbox it, right? If the intent is to only run trusted code, why is this article about spectre mitigations?

> if you are 100% sure that the code in it is trusted, then there really is no reason to sandbox it, right? If the intent is to only run trusted code,

Trusted code can have bugs; sandboxing, in a sense, is always useful (not always beneficial)

If you're running a single purpose server do you still need a sandbox though? Wouldn't a unikernel do the job and avoid the JIT compilation overhead?

It might make more sense for you to run a unikernel but it may also be important to you to use your existing tooling / monitoring infrastructure to administer your server. For example, being able to ssh into a server when things go wrong can make things a lot easier.

Reply on news.ycombinator.com