Sandboxing

[waaaaargh]

I'd like to open the discussion about sandboxing. While it surely is a nice security feature and helps with backup processes, it is not very practical.

Mail delivery agents (think dovecot, courier, ...) have different storage formats that are incompatible to each other. Converting them back and forth always bears the risk of data loss.

Additionally, If we aim for "low-end-boxes" with 256 Megabytes RAM or less, we should take into account that virtualization might not be an option and limit "sandboxing" to giving every service/app it's own UNIX user which is already implemented in nearly every GNU/Linux distribution out there.

[bastianallgeier]

Well, this is really early in the process and I completely agree with your concerns, especially as it should be targeted at rather low-end boxes as you said.

My initial thoughts were that the core system would use a pretty fixed, predefined setup of things like mail server, database servers, calendar server etc. and apps would use of the same core services and servers. Sandboxing would work in a way that for example each app would get its own database and couldn't access databases of other applications directly. The same would apply to restricted access to the file system, etc. I'm not a sys admin, so I wouldn't be of much help how such sandboxing could work, but I guess if we define exactly what would be needed, this should be doable.

The idea of using docker for entire sandboxes just seemed very convincing, but it would probably end in a massive overhead and huge application setups.

[mredd]

I'm also not a friend of patching software while integrating them into a distribution. Therefore I don't like the option of sandboxing everything, too. But the major impact of this decision should come from a more basic question: Do you want to provide a binary distribution or not?

In case of a binary distribution, I opt for an intermediate language like JVM or others. This narrows done the availability of server software (Email, file sharing, communication, etc.), but is easier to deploy on hybrid hardware architectures like x86, amd64, and ARM. I'm really not a friend of them, because they need additional resources at runtime that can be better used for the business logic itself. But they have great advantages in terms of packaging applications in a user friendly way. Another approach in the field of user friendly packaging was made by Apple with their bundle concept. The major disadvantage is, that the bundles required more space on harddisk as well as in memory. The reason is, that bundles often bring their own libraries or frameworks with sometimes slightly different versions. On modern desktop computers this is not a major disadvantage, because users are used to buy new hardware with a bigger HDD and more RAM. But on small devices like a router or an Raspberry Pi, this is a showstopper (in my opinion).

My first thoughts were also going towards a small Linux distribution. But: Is this project really aimed towards having small boxes at home and you have to clutter your DSL upstream?
If that's the intention, I share your opinion to target devices like the Raspberry Pi and provide ready-to-run images for these devices.

Ouh, there's just another thought raising up: Why not using Debian's tandem of dpkg and apt with repositories for multiple architectures. For being a developer friendly environment, we can set up a small build farm with compilers for every target architecture. Depending on the targeted developers, the farm can either crowd funded or sponsored or you have to pay for, like the difference between Goolge's AppStore and the Apple developer account (which is 99 USD a year).

[sternenseemann]

To solve the Problem with the Database access you could add something like a "Database API" that apps need to use.

• Each app has the right to own and access one DB
• The user can give Apps the right to access another DB like the Contacts DB etc.

[mredd]

Having a centrally controlled database API (controlled by the core dev team for instance) means a lot of patching of standard software or rewriting very basic things with a huge effort in rewriting and even more effort in testing and keeping it up to date.

Can some of the current idea owners point out a few use cases and examples for apps? If we can distinguish between some core functionality and some convenience apps, maybe that helps towards an easy container format and some APIs.

[sternenseemann]

then I think the best idea is to run every app under a different User which has the right to access his DB as @waaaaargh suggested. Then the access to other DBs could be managed using groups.

[bastianallgeier]

I agree that every app should have its own database and only get access to that. The communication between apps should work with a dedicated communication API. So if one app wants to access data from another app, it would use the API instead of connecting to its database directly. That way you could do things like ask users to grant access to critical data.

I also agree that a completely rewritten interface to simply access the database system wouldn't make sense. I thought that CouchDB could already solve this issue because it has its own HTTP request based interface, which is very universal out of the box.

[lx4r]

I likes @lukasepple's idea with the database access rights. This sounds very reasonable.

[waaaaargh]

I second @lukasepple's solution as well.

Here's how the setup for most* PHP webapps looks like:

• You upload stuff to a subfolder in '/var/www/
• You edit a file called config.inc.php (or something similar) and put in database login data.
• You're done.

Sometimes this is done by a installer so that you don't have to open an editor, but mostly it boils down to that.

So all we need to do is call a management script and have it create you a DBMS user and a database, return the connection info to the install process which in turn plugs it into the config file.

The only trouble I see with webapps is that especially PHP-Webapps are run as the 'www-data' user (might be called differently on distributions that are not Debian), so if there's an exploit in Wordpress and someone spawns a user shell as www-data, the attacker can in fact read any database passwords and email passwords if you have a webmail application.

[tobiastom]

To use sandboxing is IMHO very important. The end-goal of this project must be that we can install applications without breaking others, and removing applications without destroying others. Using just a plain system will take the users into a dependency hell which he will never figure out. More important: the system would not be able to figure it out itself, so it would not be able to be used by my mother.

If an application requires a newer version of Postgres (or CouchDB or whatever), it just updates it, and breaks five other applications, this would help nobody. Sandboxing has proven to be a perfect solution for it. If the application is not able to install itself, it's just broken – but it will never break the system.

Regarding performance, and the point that it should be running on very cheap hardware, I agree. I see that it is a problem, but then we need to find an adequate solution for it. Just as an example FreeBSD jails are a very low cost sandbox system, which will be able to use multiple different versions of mysql, without a huge impact on the performance.

[bastianallgeier]

I completely agree with Tobias. The goal of this project must be to create something so easy to use that even someone who can hardly handle a computer can have their own server. I'm thinking about iOS simplicity for the installation and management of applications, not another geeky solution including shell hackery and complicated update tasks. We need some sort of sandboxing that can guarantee the independence and security of apps, easy installation, updates and deinstallation.

Maybe we should start to collect the options we have and write down advantages and disadvantages. I suggest a sandboxing.md or maybe we can add it to the core.md. I'm not an expert in this case, but we should also consider if it would be possible to extract some core services and keep them global. Pretty much like you have the core APIs on a system like iOS and every app makes use of those. Maybe this can help to keep sandboxing simpler. Let's just keep in mind what kind of polish we need in the end.

[augustl]

I think Android has shown that users don't really care about sandboxing and app permissions. However, the web has shown that sandboxing can work, especially when permission is asked on demand (do you want this web site to access your current locaiton?) instead of a huge list of demands at install time.

Perhaps the database shouldn't be CouchDB but something more similar to Datomic, so that the worst thing that can happen when stuff gets "hacked" is a rollback to a previous version of the database..

[janl]

CouchDB can roll back to known state if you need to. But I think it is too early to call for any particular tech solutions yet.

[augustl]

Let me clarify that :) What I'm trying to say, is that if rollbacks are easy, perhaps sandboxing with the intent of securing your data isn't important. Sandboxing for things like dependencies (which postgresql version should we use for this app) is of course a completely different discussion.

[janl]

@augustl fair enough :) Maybe sandboxing also helps data not leak to the outside / rouge apps’ servers etc, but will depend on final model.