Hacker News new | past | comments | ask | show | jobs | submit login

There are so many servers and apps being installed by Sovereign that I'm certain few would be able to keep it secure (https://github.com/sovereign/sovereign/wiki/Software-used-by...). The big win for the cloud is that you're paying a fraction of the cost for access to a, typically, enormous security and operations team. If you want to build software like this that allows people to self-host, you need to scale down what you deploy to what a single person can reasonably manage. This isn't it.

Fun todo: Install this somewhere, nmap it for open ports, then ask "How many of these services had a remotely exploitable CVE in the last year?" "If one of these services had one tomorrow, would I know to patch it and take action faster than someone would takeover my box?" I don't see any containment mechanisms on any of these services beyond what's included by default so a compromise of one service likely leads to total compromise of the entire box.

I had to think about this a lot with AlgoVPN (https://github.com/trailofbits/algo), and we built a system with no out-of-the-box remote administration, strong isolation between services with AppArmor, CPU accounting, and privilege reductions, and limited third party dependencies and software. You can't count on a full-time, expert system administrator.




This touches on a problem I've been thinking about a lot. AWS, etc, have solved the problem of hardware operation. Containerization is doing the same for OS operation. I think the next thing is app operation.

For some things, I'm happy to use SaaS providers, where they are responsible for the whole stack. For others, I'm happy to use apps, where they just provide the code, and I provide the platform. But for a number of things, I want something in between: I provide storage and compute, they provide code and operations.

Bitwarden for me is a good example. They're a password manager who provides their backend as a docker container anybody can run. I like that, as I don't really want them to have my data, and if they go out of business, I don't want to be cut off from my passwords. But I won't run the backend myself, because I don't have the time and expertise necessary to make sure it stays secure.

Another good example is photo hosting. I would rather keep all my photos on space I control. But I also need modern, maintained software for syncing, serving, and controlling access to photos and related data. I'm happy to pay somebody to make and maintain that software, but not nearly as happy if that means that at any point they might shut down and take my data with them.

I suspect we're headed toward a future where people like Synology and Digital Ocean sell storage+compute, and then other companies sell and maintain user-selected software that runs on those environments. Basically, some sort of app store for servers. But I'd love to see this happen in an open, nonproprietary way, as the drawbacks of Apple's and Google's app stores have become pretty clear.


Sandstorm was a really nice solution to this, but it required each app to be integrated with it, which I personally think is what killed it. (Which sucked, because for what it supported it was the best option available)


Ah, interesting! Just reading the home page wearing my developer hat makes this stand out: "Each document, chat room, mail box, notebook, blog, or anything else you create is a "grain" in Sandstorm. Sandstorm containerizes each one in its own secure sandbox from which it cannot talk to the world without express permission."

The notion that every document is its own independent unit sounds pretty menacing to me. Could be fine for some things, but getting things running there is sounding like a fair bit of work to me, and very limited.

And then this part is especially bad: "[maybe someday] You won't have to deal with payments | Eventually, we hope to make Sansdtorm implement in-app purchases and deposit the proceeds directly to your bank account"

Right there a lot of incentive to integrate has leaked out. "Please build for our platform in exchange for no money" is not quite the worst offer I've had, but it's definitely not appealing. Looking through the Wayback machine, I see

But the part that really concerns me is that they seem to think that server apps can run like mobile apps. To me one of the most powerful things about SaaS products is that the aggregated use information drives both product and operational improvements and allows rapid response to bugs and issues. So as a developer choosing between this and a SaaS approach, this feels like having one foot in a bucket to me.

For example, I recently outsourced my mail hosting to Fastmail precisely because I want experts to run things. Would I be happier if the data were stored somewhere I control? Definitely. But not if that means the experts aren't paying attention anymore.


Sandstorm's design is a little bit menacing! And it does require a fair bit of work sometimes to fit web apps not built for Sandstorm into Sandstorm's model. (The holy grail here is apps built for Sandstorm, but the platform needs to be bigger before more developers do that.) Usually packaging for Sandstorm largely entails locking an app into a single-document model, and stripping out authentication (since Sandstorm handles it).

But the end goal is pretty well worth it: Any grain is incredibly secure by default, and for the most part, app vulnerabilities are irrelevant. A grain where only you have access doesn't need any sort of authentication or security in the app at all. And since each document is it's own sandbox, sharing a document with someone doesn't give them a way in to exploit access to your other documents as might happen with a vulnerability in a more traditional design.

The business model story for selling Sandstorm apps isn't super great right now, you probably could have a licensing model that requested network access through the Powerbox to check the license or something, but in many cases, there's already a wide variety of great open source apps that are free and just frustrating to host and manage without a platform like Sandstorm (or Cloudron). (EDIT: Now that I think about it, Sandstorm used to have a paid license key/feature key system that made no callbacks, I think the licensing info was encrypted asymmetrically.)

As for your support of SaaS data collection, I just can't really agree with you: People who want to give data to a developer can choose to do so, but I think it's ethically wrong to collect data without permission. (Sandstorm servers do have the ability to opt in to provide basic app usage data back to Sandstorm's development team.)

I love FastMail, and have been an enthusiastic customer since 2016. :)


I feel the exact same way and am currently trying to solve this by decoupling the application from the storage. So the "experts" control the business logic and UI, while I, the user, store the data. It's similar to what Firebase does for app developers but is split by the end user who can also control that data.

> But the part that really concerns me is that they seem to think that server apps can run like mobile apps. To me one of the most powerful things about SaaS products is that the aggregated use...

That definitely seems like the current state of affairs but I think there isn't a reason why writing server apps like mobile apps has to inherently throw away aggregated data. Especially with Google's research in federated learning, apps will soon be able to get insights across their users while preserving their privacy.


Please don't past-tense Sandstorm! The community is still working on it. Albeit a little slower. ;)


I actually didn't realize that. I think I confluated the death of Oasis with Sandstorm in general. I'll have to poke into running it:) Thanks for the correction!


Maybe something like this https://remotestorage.io/ becomes popular. I would love to make apps that use user owned universal storage/server.


> Fun todo: Install this somewhere, nmap it for open ports, then ask "How many of these services had a remotely exploitable CVE in the last year?" "If one of these services had one tomorrow, would I know to patch it and take action faster than someone would takeover my box?" I don't see any containment mechanisms on any of these services beyond what's included by default so a compromise of one service likely leads to total compromise of the entire box.

This is the same concern I have with self-hosting anything with sensitive personal information on it. Without continuous monitoring, alerts and periodic review of audit trails, it’s anybody’s guess what’s going on with all the self-hosters’ data. With larger companies that provide a SaaS solution, there’s a little more hope that someone is looking at this seriously all the time.


fail2ban and rkhunter are in the kit, and that offsets some of the issues: you get some assurance and protection right there out of the box.

You can also comment out the bits you don't want from https://github.com/sovereign/sovereign/blob/master/site.yml before you run the top level playbook.


fail2ban is security theater. Turn off password-based ssh authentication, use keys only, and you’re done. You don’t need additional software for it.

For extra security, bind ssh to localhost only and run a tor hidden service on the machine for accessing it.


These are fair points.

If I were to provide services for me and my family (or for a small company), I won't make them publicly available at all.

I would have every device connected to them over VPN (OpenVPN, WireGuard, ZeroTier). Of course it would prevent self-registration, and would take some work to distribute keys — but by definition we are a small operation, so this is manageable.

No service would ever listen on a publicly accessible IP. The machine(s) hosting that would firewall off all other incoming connections, except the VPN and SSH for admin purposes. I hope I would be able to quickly address CVEs in these two services, plus the kernel.

A setup like this is already pretty standard with AWS, but you can reproduce it almost anywhere, including your own physical box(es).

The weakest link with this setup is the client computers. So inside the VPN you still need good security practices — but the attack surface becomes much smaller, and a DDoS becomes harder to pull off.


You're not expected to use and install all of the services offered by Sovereign, just as you're not expected to install all packages of your Linus distribution. I guess we need to make this more explicit in the documentation. Just pick services you plan to use during the installation phase as outlined in the instructions.


The documentation instructs you to pick the services you plan NOT to use:

> Don’t want one or more of the above services? Comment out the relevant role in site.yml.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: