5 ms·

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/wik

by dguido 7y ago

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-Sovereign 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 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.

PaulRobinson 7y ago
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 https://github.com/sovereign/sovereign/blob/master/site.yml before you run the top level playbook.
- sneak 7y ago
  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.
wpietri 7y ago
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.
- omnimus 7y ago
  Maybe something like this https://remotestorage.io/ https://remotestorage.io/ becomes popular. I would love to make apps that use user owned universal storage/server.
- yjftsjthsd-h 7y ago
  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)
  - ocdtrekkie 7y ago
Tepix 7y ago
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.
- Domenic_S 7y ago
  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.
newscracker 7y ago
> 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.
nine_k 7y ago
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.

by dguido 7y ago

PaulRobinson 7y ago

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 https://github.com/sovereign/sovereign/blob/master/site.yml before you run the top level playbook.

sneak 7y ago
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.

wpietri 7y ago

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.

omnimus 7y ago
Maybe something like this https://remotestorage.io/ https://remotestorage.io/ becomes popular. I would love to make apps that use user owned universal storage/server.
yjftsjthsd-h 7y ago
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)
- ocdtrekkie 7y ago

Tepix 7y ago

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.

Domenic_S 7y ago
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.

newscracker 7y ago

> 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.

nine_k 7y ago

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.