Operating system was always a vague term.
Yes it's not Windows but it's a system that host user applications, seems valid to me.
Yes it's not Windows but it's a system that host user applications, seems valid to me.
Unless you're Richard Stallman, it really isn't.
https://en.wikipedia.org/wiki/Operating_system
Do you have a kernel, and manage hardware? Then you're an OS. Otherwise, you're a container, or app server, or some other type of "platform".
Tomcat and Jetty host user applications. They're not operating systems.
[1]: It requires that the Linux kernel be compiled with `CONFIG_USER_NS=y`, which has multiple privilege escalation vulnerabilities, disabled by default on most distros[2]. If you turn it on, you are saying "all of the non-root code that I am running is managed by a trusted seccomp monitor process that prevents it from using user namespaces" which effectively means "all of the non-root code I'm running is running inside of Sandstorm".
[2]: Many distros (Debian, Ubuntu, CentOS) actually have `CONFIG_USER_NS=y`, but patch the kernel to make it be run-time configurable via a sysctl flag (the flag set to "off" by default). This doesn't change the fact that turning it on (whether it be via a compile-time flag or a run-time flag) makes it unsuitable for normal use.
$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
$ grep CONFIG_USER_NS /boot/config-3.10.0-327.22.2.el7.x86_64
CONFIG_USER_NS=yThat doesn't change the fact that turning it on (and expecting to not introduce significant vulnerabilities by doing so) is saying "I'm running a significantly different userland than the standard one."
I wouldn't recommend enabling it on a server that gives out shell accounts to multiple mutually non-trusting users...
... but I also wouldn't recommend operating such a server, period. Linux has too many vulnerabilities on a regular basis for it to be practical -- yes, many are userns-related, but many aren't.
On a single-user desktop, enabling user namespaces is irrelevant. (User-root separation does not matter on a single-user desktop. All your sensitive data is in your home directory.)
On a server machine that runs one service, again, enabling user namespaces has no significant security impact. If you are running multiple services on one machine and relying on UID separation (with no other sandboxing) for defense-in-depth, then, sure, enabling userns adds risk -- but again, disabling userns does not completely eliminate the risk.
But, I think it is reasonable to trust UID separation and the Unix permissions model. Linux is not that vulnerable. With some diligence, a server can securely provide access to computational resources to multiple mutually non-trusting users, through the mechanism of Unix permissions. And it's really the only hope we have.
Not at all. We have better sandboxing mechanisms now.
> If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right?
UID separation has broken down because the attack surface has grown too large, encompassing:
* The entire ever-growing system call list.
* The huge /proc and /sys filesystems, which let you muck with all kinds of process and system state.
* Devices in /dev, many connected to low-quality device driver code.
* Every setuid-root binary installed on the system.
When the API gets that huge, avoiding bugs across the whole thing gets impossible.
Modern sandboxes work by massively reducing this surface. Sandstorm apps are restricted to a core set of common system calls, do not get /proc or /sys, only get a couple devices in /dev, and cannot use setuid-root binaries. In this situation, security is much easier.
Moreover, we use a capability-based security model to permit apps to talk to each other and the world, rather than an ACL-based one. This model makes it much easier to start from zero and grow, rather than starting from everything being accessible and then shrink.
> And it's really the only hope we have.
Luckily, it is not.
The original MacOS didn't either (it was a collection of subroutines in ROM that user programs would call into), but was also generally considered an OS.
But it's definitely an OS in the sense that it provides tooling, build and distribution infrastructure, plus OS-type services such as message passing APIs, standard plugin interfaces, etc.
Long story short, semantic arguments aren't interesting and there's no logical argument against calling Sandstorm an operating system.