Background
First, it should be completely possible to use OSTree to create "embedded systems" or "software appliances" which are combinations of OS+App, where the given application is to the OS, and can't be removed or changed. So OSTree should not mandate any particular application system. However, GNOME clearly desires a application model, and even for embedded users, it's useful to have some separation between the two.
Goals
- Allow installing and uninstalling applications without changing the OS
- Applications are independent of each other
- Clear *branding* difference between applications and OS
- Applications are controlled by their authors
- Promote Free Software applications, but support installation of non-Free software
Related projects
There's a huge amount of prior art here; the Glick 2 page links to some.
Implementation/Security
A fundamental feature that the OS application system should have is the ability to uninstall an application, even if it is malicious. Obviously, it's desirable as well if malicious applications can't do other "bad things" such as deleting all of the files in your home directory, but being able to uninstall is the most fundamentally necessary operation.
Implementing this leads one to a few conclusions:
- There must be a reliable means to return the user interface to complete operating system control, where no applications can e.g. render a fullscreen UI or intercept keystrokes
- Applications must not be able to mutate the operating system or other applications (either on disk, or running processes)
This architecture is what Apple has on iOS. The first part is the single hardware button on the front of the device. The second is accomplished by various security mechanisms. Implementing this in the current GNOME stack is a challenge.
Process isolation
First, I don't think we can do what Android does and try to run every application as a separate uid. It has some clearly nice things, but it's too much of an architectural change at this point; it would require invasive changes in everything from PAM to PolicyKit, and even doing that would leave open the question of how /home works (what uids are files written as?). This means we should look at using SELinux security contexts or equivalent to ensure applications can't use ptrace() on one another, etc.
Write XOR Execute for files
Basically, it should not be possible for applications to create executable files, since that would be a way for them to stay installed. Because they can write to /home/user, that means that /home/user must not be able to contain executable files; as a first pass at this, mounting /home noexec. Also, it means that when the operating system installs an application, the application executable must not be writable by the user's uid (even if the application is installed just for that user).
Non-kernel mechanisms for inter-process control
These are basically the X server and DBus. We need to restrict the ability for applications to operate on these arbitrarily. Both of these have SELinux support; if the system policy simply denies having these separate applications communicate, it may be enough.
Implementation Feasability
In reality, we won't get this right in a first pass; there will be holes, but we will fix them over time. The point is that I believe the above to be feasible with a few person-years of work. Android has a more complete application sandboxing system, but the individual permissions are full of holes; it doesn't really work.
App Stores
Basically, I don't think GNOME as a volunteer-driven, Free Software focused project can host one. We can't guarantee to people that the uploaded code is not malicious. Requiring everything to be Free Software would help, but that doesn't magically create code reviewers. Bottom line: GNOME will come as a software source with a few core apps (Epiphany, Documents, gEdit etc.), but we expect people to add third party application sources. In other words, application authors host their own websites.