Sandstorm implements a capability-based security model, where not only does each app run in a strong sandbox, but a new instance of the app is created for each document (or whatever the app's logical unit of data may be). Sandstorm itself enforces that each document can only be accessed by the people with whom it has been shared, regardless of any bugs that might exist in the app itself. All communications between the user's browser and the app go through a proxy implemented by Sandstorm which applies this authorization regime.
Apps cannot even talk to each other or the internet without specifically requesting access, granted by the user. The UX model for these requests is designed to flow naturally for the user, by deriving the user's intent to permit access from the action they took that caused the access to be needed. For example, say the user wants to embed a chart into a document, where the chart editor and document editor are separate apps. The user clicks some sort of "embed" button in the document editor. Now they are presented with a chooser where they can pick which thing they want to embed. If they make a choice, there is no need to separately ask the user if they want the document to have access to the chart -- of course they do. Sandstorm works by having the system implement the "picker" UI directly, so that Sandstorm knows the user made this choice, and can automatically provide the implied authorization.
All this actually makes apps easier to write since they don't have to deal with authorization and user management themselves, and as a result there are a lot of neat unique apps for Sandstorm written by various people in a short amount of time. However, the down side is that existing off-the-shelf apps that do already feature their own user management and authorization are somewhat laborious to port to Sandstorm.
Yunohost takes a more traditional model of just running each app and letting it figure out its own authorization.
Cloudron is pretty cool, and Docker containers definitely help, but there's a huge security difference between what Docker provides and what Sandstorm does. One of the biggest differences is that most plain Docker-based self-hosting platforms isolate at the app level. Sandstorm isolates individual documents, which often means Sandstorm apps are protected from their own internal flaws as well.
Also, Cloudron is not open source and you need a subscription to use it generally. This has led it to be more successful of a business venture, of course, but is a big downside for software freedom.
What would an application do that is more secure than namespaces+cgroups? Containers absolutely are a security tool (especially if you configure your capabilities and don't use PID 1), one with a security tradeoffs compared to real virtualization, sure, but you're not going to do that on a VPS.
Docker (or Podman) is just a tool that sets up some linux primitives for you. One with a track record and volume of users that'd make me trust it over things that specifically advertise themselves as "security sandboxes" (i.e. firejail, who had some extremely funny basic exploits to get root from their SUID'd binary). You can even pair containers with user namespaces now and get the fakeroot equivalent of containers.
> What would an application do that is more secure than namespaces+cgroups?
Object capabilities, which is what Sandstorm/Cap’n Proto are based on, provides much more security than Mandatory Access Control systems while also providing a much simpler method for getting there.
Sadly the literature on OCAP is fairly poor, often being either too low level or too abstract.
The tl;dr is that OCAP systems work by assuming an application has no functionality whatsoever, and then must be passed (not sandboxed but passed) functionality, either at start time, or when the application requests it.
The easiest way to understand it is imagine if instead of being able to open a file on the filesystem by path, you had to specifically be passed the file descriptor by the OS, possibly before runtime.
Another way to think about it is thinking about the OAuth2 capabilities that you can grant an application. You authorize an application to have certain capabilities, and then the client is handed back a set of API tokens or addresses. Those are the only way it can exercise those capabilities.
It's not being sandboxed, it simply doesn't have any additional way to get access.
That seems interesting and like a technically correct way to go, but also I can see nobody adopting it on a general purpose operating system and thus rendering it useless. Getting developers to use portals already is hard enough.
That's pretty much my job. Can you be more concrete with what you're talking about instead of this passive agressive "you don't know what you're talking about" tone?
Flatpak and Snap are pretty much using the same primitives as containers, they just don't like using the word because of existing connotations. Mandatory access controls are neat, but nobody actually uses them unless the default doesn't disturb them or they have a compliance requirement.
> A pretty poor track record.
Modern containerd, after having been split up from Docker/Moby, has a better track record than most other sandboxing tools. I mentioned a laughably bad one that the Arch wiki and many HN users still seem to endorse.
"Security" really ought not going to be much of a selling point, since no one is particularly good at it these days; I'd be shocked if this thing could actually point to meaningful, as opposed to theoretical, security advantages.
Sandstorm is really good at security. I would absolutely encourage you to download a copy and try to identify an exploitable security vulnerability. As a Sandstorm user, I'd really like to know about it!
I suppose I'm talking about marginal differences. As in, I'd be surprised if Sandstorm can strongly outdo, e.g. my own Docker + Nginx proxy manager+SSL stuff?
You will be surprised then. Sandstorm utilizes capability-based security to grant access to applications, each app is only ever running when an authorized user attempts to launch the app, and each document within a given app is isolated to it's own only-run-on-demand container.
The core difference here is that for all intents and purposes app vulnerabilities are almost wholly mitigated. The only significant type of app vulnerability which Sandstorm cannot prevent is privilege escalation within a single document, where you've shared limit access of a document with a user, say read only, and due to an app vulnerability, they've figured out how to edit it.
Since all documents are private solely to the user who created them initially, and the process isn't even running until that particular user tries to open it, there's effectively no attack surface for Sandstorm apps most of the time. When they are spawned, they're spun up at randomly-generated ethereal subdomains, and authorized solely for access by the web browser that launched them.
I understand where you're coming from, and I would encourage you to get familiar with object capabilities, as it is one of those big pieces of hitherto-ignored low-hanging fruit.
