Hacker News Reader

Comment by missjellyfish | Hacker News Reader

So basically you now run your app in ring0, with none of the security mitigations the community developed in the past ten years, and force everybody to code in c/c++. Is it just me or does that sound like a disaster waiting to happen?

View on HN

It’s a single process running inside a sandboxed VM. That process might not have code written for reading files from disk (let alone writing them) or a full TCP/IP stack (let alone the ability to forward SSH sessions) and it certainly wouldn’t have any capabilities of launching a remote shell. So you’re not going to be susceptible to the vast majority RCE vulnerabilities that happen with even a minimal GNU/Linux port. Even if sloppy C++ coding did make you vulnerable, you’re still stuck inside the VM with literally nothing available aside that process.

The bigger risk is DDoS attacks but that’s risk when writing sloppy code in any language, runtime and hosting environment.

What security systems do you need if it's the only thing running on the computer/vm/container?

All of them if any external party has access to that "only thing running".

Do you really need something like SELinux if the “only thing running” is a network service that doesn’t have access to a file system? Even if that service was compromised, what else could be gained? Especially if the unikernel doesn’t spawn other processes.

Am I missing something obvious?

Nope, you are right on the money. It’s just new and different, and people don’t like new and different.

Not being able to spawn other processes is actually a huge security and performance benefit when you know you're deploying to a virtualized environment to begin with. (eg: cloud).

No, not missing anything. Trendiness wars with actual benefit.

"the computer industry is more fashionable than the women's fashion industry" - Stallman

But that's the same either way, isn't it? If an attacker compromises your application, they own the app. It doesn't matter if the app is under an OS or a VM.

Most (all?) attackers dont care about apps. They want access to your server to do other things. That could be downloading a monero miner or doing something as simple as mysqldump. Either way that's another program which isn't possible in a single process world such as a unikernel.

On the other hand this is a single application running in its own VM, so it also makes isolation easier/lighter.

I don't actually have a lot of experience/knowledge about this, but here goes.

Two ways to address those concerns:

- Your app runs on bare metal and security is implemented on the network layer. For example, something external to app handles authentication and you have something in front of the bare metal box examining and approving requests (like other apps).

- Your app runs in a VM and the hypervisor handles security.

The local user-based security model has been insufficient on the server end of things ever since publicly widely accessible cluters of HTTP servers with load balancers became the norm. Of course you want to protect the local server but we're much more interested in authenticating and applying security beyond the boundaries of any individual OS. There is LDAP and numerous standards but they require implementation beyond the OS - your own or reliance on a third party like Google or Microsoft. If you have to reimplement this with microservices then who cares about the local OS?

A microservice that is only spoken to via HTTP GET or POST requests could get away with removing a lot of things in a traditional OS, such as shells, TTYs, console support, all drivers unrelated to CPU features or networking (no SCSI, floppy, etc.), all drivers unrelated to sending/receiving data through a NIC (no xtables support, no NAT/routing, no weird TCP options no one uses, no weird protocols no one users, no conntrack), no dnotify/inotify support, and maybe even go so far as to remove code behind syscalls that the app doesn't actually use. No TTY support means no one's logging in, so who cares about users at this point?

A non-microservice app, like CGI scripts invoked via Apache, is probably a poor choice for unikernel, but a front-end caching webserver may not be.

There is no such language as C/C++.

The alternative for people using this approach is running in a kernel module, or a kernel-bypass setup with root permissions. Grown-up stuff. Eliminating most of the kernel, and using C++ not C is a very substantial improvement over status quo.

> There is no such language as C/C++.

This is a really weird hill to die on; I see you've made the same comment several times in this thread. C and C++ fit hand in glove, and lots of folks use them in conjunction. I don't think anybody here has the misconception that C/C++ is a single language, unless perhaps they don't know either.

The point is that the practices that almost unavoidably lead to bugs in C code are not even tempting in modern C++. So, if you are interested in correctness and memory safety, stepping to modern C++ provides more value for time invested than the sum of most other choices.

Equating the two is extremely common, even by people who are certainly equipped to know better. When you feel a need to tar C++ as if it were C, you signal the weakness of your argument before you have even expressed it.

"Modern C++" is a term that mostly just means "C++ sans the C parts". So yeah, it's different than C.

> you signal the weakness of your argument before you have even expressed it.

Please turn down your flamethrower, that style of conversation is not welcome here.

Writing "C/C++", in contexts where it is implied they have the same failure modes, is provocative. Don't like response, don't provoke.

It is fine when talking about ABI or object-code generation.

C/C++ means either C or C++. Most compilers allow your project to contain both C and C++ source code at the same time.

Or Rust and C. Rust calls C libraries easily. So, is it Rust, or is it C/Rust? You choose.

The failure modes of Rust code are very different from C's, but calling C libraries, as is usually a practical necessity in production, exposes you to all of them.

Switching to modern C++ nets 90% of the benefit (plus other benefits Rust lacks, and may always lack) for 10% of the cost and 0% of the hump.

So, is it C/Rust and C/C++, or Rust and C++?

Obviously it's Rust/C/C++/Python/Ruby/Java/Kotlin/Scala/JavaScript/TypeScript/Perl/Haskell/OCaml/Lisp/Racket

The "/" symbol is an infinitely extensible shorthand for a union.

Well, remind me of “Premature optimisation is root of all devil”. This is not an optimisation, but it tripped many parts.

Reply on news.ycombinator.com