8 ms·

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

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?

docuru 7y ago
Well, remind me of “Premature optimisation is root of all devil”. This is not an optimisation, but it tripped many parts.
pushpop 7y ago
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.
mavhc 7y ago
What security systems do you need if it's the only thing running on the computer/vm/container?
- alfanick 7y ago
  All of them if any external party has access to that "only thing running".
  - mbreese 7y ago
    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?
    - ncmncm 7y ago
      No, not missing anything. Trendiness wars with actual benefit.
      - nintendo1889 7y ago
        "the computer industry is more fashionable than the women's fashion industry" - Stallman
    - x0054 7y ago
      Nope, you are right on the money. It’s just new and different, and people don’t like new and different.
    - eyberg 7y ago
      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).
  - yjftsjthsd-h 7y ago
    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.
    - eyberg 7y ago
      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.
leni536 7y ago
On the other hand this is a single application running in its own VM, so it also makes isolation easier/lighter.
ncmncm 7y ago
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.
- klyrs 7y ago
  > 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.
  - ncmncm 7y ago
    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.
    - klyrs 7y ago
      > 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.
      - ncmncm 7y ago
        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.
    - paulddraper 7y ago
tenebrisalietum 7y ago
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.

docuru 7y ago

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

pushpop 7y ago

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.

mavhc 7y ago

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

alfanick 7y ago
All of them if any external party has access to that "only thing running".
- mbreese 7y ago
  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?
  - ncmncm 7y ago
    No, not missing anything. Trendiness wars with actual benefit.
    - nintendo1889 7y ago
      "the computer industry is more fashionable than the women's fashion industry" - Stallman
  - x0054 7y ago
    Nope, you are right on the money. It’s just new and different, and people don’t like new and different.
  - eyberg 7y ago
    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).
- yjftsjthsd-h 7y ago
  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.
  - eyberg 7y ago
    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.

leni536 7y ago

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

ncmncm 7y ago

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.

klyrs 7y ago
> 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.
- ncmncm 7y ago
  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.
  - klyrs 7y ago
    > 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.
    - ncmncm 7y ago
      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.
  - paulddraper 7y ago

tenebrisalietum 7y ago

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.