Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This feels specious:

> The result of this is a very small and fast machine that has fewer security issues than traditional operating systems (because you strip out so much from the operating system, the attack surface becomes very small, too).

Obviously traditional operating systems provide a lot of interfaces that represent attack surface, but they're generally able to be secured. On the other hand, much of the operating system actually _implements_ security, so if you throw it out, you're losing that.



In the way that unikernels are typically used, each unikernel instance runs as a VM, and security is implemented by the hypervisor. If the VM is just running one application, it doesn't need its own mechanism for allowing mutually distrusting users to run their own code.


If the hypervisor is providing the security, I don't see how the unikernel can be said to be any more secure than anything else run under a hypervisor. Moreover, I don't see why the hypervisor should be in a better position to be secure than a kernel.


Implements security theatre. If the OS is immutable then there's nowhere to persist an exploit.

A server could be killed and restarted at the first sign of compromise. If you aren't loading GBs worth of modules that'll never be uses, the OS will be able to boot up in a few seconds max.


What do you mean by immutable?

If you're talking about the on-disk files, that's possible to do without throwing away almost everything -- Solaris does this using read-only zones (ROZR).

If you're talking about the kernel itself; that can never be truly immutable. An OS had to read and write memory.

I also don't understand the claim about "GBs worth of modules"; if you're talking about kernel modules, there shouldn't be "GBs" to start with.

As for security theatre; I hardly think crypto support, auditing frameworks, qualify. So you need to define that as well.


Immutable as in filesystem.

Meaning every restart brings the system back to a fresh state. Most trojans/backdoors persist because they're able to modify the underlying OS to load them on boot. No, immutable OSes are -- by no means -- a new idea. This just uses the approach by default.

Not talking about the kernel specifically. Although there's no reason the bootup time should be slowed down by loading unnecessary HAL, drivers, protocols, utilities that will never be used in a server setup. GBs of modules was referring to the rest of the OS made up mostly of features that will never be used by the server.

Crypto support is one big issue. I'd assume if the OS uses V8 at the base level, it should be able to be packaged with OpenSSL.

Auditing for what exactly? File access? The filesystem is immutable. Network requests? Can ve handles at the network level or a tool can be added to log network requests via an offline logging service.

Security auditing at the OS level isn't required to the same degree it is on other OSes because the attack surface is so small. For instance, you don't have to check for SSH vulnerabilities when there's no SSH. The userspace sandbox isn't necessary because everything that's network-facing already has to run through V8's sandbox.

Application-level vulnerabilities will always be an issue but that's nothing new. This doesn't solve all problems. Just reduces the potential for issues.


Meaning every restart brings the system back to a fresh state. Most trojans/backdoors persist because they're able to modify the underlying OS to load them on boot. No, immutable OSes are -- by no means -- a new idea. This just uses the approach by default.

Ok, then yes, Solaris read-only zones provide that level of immutability.

Not talking about the kernel specifically. Although there's no reason the bootup time should be slowed down by loading unnecessary HAL, drivers, protocols, utilities that will never be used in a server setup. GBs of modules was referring to the rest of the OS made up mostly of features that will never be used by the server.

A good operating system will be smart enough to only load what it needs; there will be some inefficiency, but protocols, drivers, HAL are actually used in server setups and are not usually the source of significantly increased boot times unless they're misconfigured. Also, with a proper service management facility and packaging, it should be possible to simply omit unnecessary items; services are usually what contribute the most to startup time.

Crypto support is one big issue. I'd assume if the OS uses V8 at the base level, it should be able to be packaged with OpenSSL.

Right, but you generally need more crypto administrative capability than OpenSSL alone provides to manage a sufficiently complex application. (e.g. gnupg, etc.)

Security auditing at the OS level isn't required to the same degree it is on other OSes because the attack surface is so small.

Sorry, I'll have to disagree on that point. Auditing is always important because it allows you to determine what happened and why when privileged operations are involved. The overhead of auditing is almost completely determined by what an administrator chooses to audit and how detailed that auditing is.

For instance, you don't have to check for SSH vulnerabilities when there's no SSH.

Perhaps you misunderstood what I referred to when I spoke of auditing; I don't speak of checking for vulnerabilities -- packaging should generally handle that in combination with metadata and reporting. I was referring to the recording of the assumption of privileged operations, system authentication, and related details.

The userspace sandbox isn't necessary because everything that's network-facing already has to run through V8's sandbox.

Disagree again; the point of having a userspace sandbox is in case something escapes V8's sandbox, which has been done in the past. It's an extra line of defense.

Application-level vulnerabilities will always be an issue but that's nothing new. This doesn't solve all problems. Just reduces the potential for issues.

While it reduces the number of problems in the existing space, I personally believe it creates new problems. I'm not sure the tradeoffs are worth it.

I would rather see an immutable container with a minimised set of packages with proper auditing enabled. That's far easier to test and deploy and doesn't create new problems.


Persistence is not required for an exploit. Repeatability is just as bad. Restarting in response to compromise means every compromise is a DoS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: