[runeks]

    > Until we fix this RCE vulnerability, the attacker will 
    > still be able to execute code on our host [...]

With Docker, it seems to me like we're moving closer and closer to the server being an executable of its own, but with the necessary Linux kernel bits compiled in such that it can execute on (virtualized) hardware.

I'm wondering how far we can take this. The ability to execute code on the host is there because that's what Linux does, but what if we removed this interface, and replaced it with an interface that just accepts one or more ELF binaries at compile-time? Then these would become the only Linux executables that this kernel can execute.

As far as I can see, we could do the same to system calls: if an executable can enumerate all the system calls it needs, we can compile a kernel that will accept only these system calls, which should be a small subset of all available Linux syscalls.

[stable-point]

This is called a Unikernel: https://en.wikipedia.org/wiki/Unikernel

> Unikernels are specialised, single address space machine images constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.

[runeks]

That is correct. I guess what I wanted to point out is that it would be cool if Linux could become this - a library that you can compile into your program, rather than a program in which you run your programs (an OS).

[justincormack]

There is a library port of Linux, lkl https://github.com/lkl

[paulddraper]

Linux is purposefully and by design monolithic.

However, you could base your unikernal capabilities on the same interface (like POSIX).

Current unikernals: http://unikernel.org/projects/

[digi_owl]

The GPL would likely give any legal department pause for thought in that regard.

[digi_owl]

Or as i like to call them, DOS-in-a-can...

[nickpsecurity]

That's not fair given DOS was 100% unsafe in architecture and implementation language. The Ocaml or Rust ones are more like the Pascal OS's (eg Solo) with a certain amount of safety built-in. I agree on the minimal part but the overall metaphor doesn't fit.

[paulddraper]

DOS like Denial of Service? Or DOS like MS-DOS?

Either one doesn't make sense to me.

[digi_owl]

the latter.

DOS was a downright minimal layer of code between the software and the hardware.

Little to no memory protection etc.

If it walks like a duck and quacks like a duck...

[zokier]

> As far as I can see, we could do the same to system calls: if an executable can enumerate all the system calls it needs, we can compile a kernel that will accept only these system calls, which should be a small subset of all available Linux syscalls.

That is what pledge essentially does at runtime

http://man.openbsd.org/pledge

[SixSigma]

This industry is one of the least aware of its own history, everyone is focussed on tomorrow. We should really include History of Computing as a discipline. Round and Round and Round we go.

---

You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you.

        — Ron Minnich

[digi_owl]

I wonder how much of that has to do with the mainframe-minicomp era having been largely insular relative to the wider population.

Keep in mind that todays server hardware traces its lineage back to IBMs response to microcomputers like the AppleII and C64.