Actually, I agree. We originally used the term "platform". But, we found that people understood more easily when we switched to "operating system" -- and it's not too far off the mark, honestly. Sandstorm is an OS in the sense that Android is an OS. Both use the Linux kernel, but largely control the userspace. (Sandstorm can run along-side your existing Linux distro without interfering with anything, but it doesn't really use any of your distro's infrastructure so this is somewhat of a technicality.)
The problem with "platform", which surprised me, is that a lot of people now think "platform" is somehow synonymous with "cloud service". For example, if you watch HBO's Silicon Valley, you may remember the whole "platform vs. box" debate from this season. It's a frustrating perversion of the word, but it is what it is.
It's actually restricting our thought to an annoying extent that we've overloaded the term "operating system" so much. This isn't Sandstorm's fault -- Windows already has billions of people thinking "operating system" == "desktop environment" so the ship has already sailed.
I would really like a word that describes this set:
+ Unix CLI
+ WIMP desktops
+ Browsers
+ iOS touch interface
+ Android touch interface
+ Emacs (when used for general computing)
Perhaps "user environment" would work?
EDIT: For me at least "platform" doesn't quite fit. I think whatever word is best should imply "single user interface" which platform doesn't necessarily.
My concern with the misuse of the world "operating system" is that I've seen this trend noticably devalues the term in my own operating system projects, which are actual operating systems.
To run it on your existing operating system, you would need to modify the Linux kernel in such a way that makes it unsuitable for running other services.[1] I'm fine viewing it as a specialized operating system built on the Linux kernel.
[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.
Ok, so more distros patch it to be a run-time sysctl flag than I thought.
That 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.
If we can't even trust UID separation to work, then the project of secure computing is hopeless. We've been working on UID separation for decades. If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? Furthermore, abandoning the Unix permissions model requires us to rewrite the world. (a rewrite that, admittedly, Sandstorm has already made some great progress on)
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.
> If we can't even trust UID separation to work, then the project of secure computing is hopeless.
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.
Android has no kernel (it uses Linux), but most people think Android as an OS.
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 unlike Android you can easily install sandstorm.io on different linux distros, in fact I don't even think there is an installable OS image available.
There's a distro that back in the day did not have installable images; they only had a script to install it from an existing distro (I think it was Gentoo, but I'm not sure on that). Given that with Sandstorm, you are essentially replacing the standard GNU et al. userland with the Sandstorm userland (since turning on user namespaces with the standard userland would allow every user to be root), I don't think that it is unreasonable to view Sandstorm that way either.
ROS is Robot Operating System— it runs on top of other operating systems, like Linux, Windows, and Mac 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.
So are you saying operating system is a subclass of platform? I guess but that distinction doesn't seem very useful. It seems more like the term operating system has aged. I'd rather call Windows/Linux a platform instead of an operating system and indeed other people do too. Even then, some people consider it a design smell to consider software a platform.
Long story short, semantic arguments aren't interesting and there's no logical argument against calling Sandstorm an operating system.
In technical reality, it seems to be a Google Apps alternative that you can self-host.
Still very cool (frankly even MORE cool than yet another hobby OS!)... but "platform" would be a less groan-worthy phrase than "operating system".