ApplicationPackagingAndSandboxing

Summary

A system for packaging, distributing, and safely executing applications based on the ideas of application directories and software sandboxing. Similar to Klik, Autopackage or Portable Apps

Release Note

This system completely protects your system from virus, makes it easier to get and share software, and improves the system speed and stability by preventing "software rot".

Rationale

The current software distribution method relies on a "sources" list, scatters parts of the application through the whole system, and executes it with only a very basic security. This has a large number of problems: it makes it hard or impossible for developers to distribute their applications, makes it hard to find files related to an application and remove/copy them, makes some users more unwilling to try software, allows for software to modify the system and potentially damage it, etc. In practice almost no applications really need to be installed, and could be executed from any folder with the same efficacy.

This method is partially inspired in the simplicity of Flash games: you go to a webpage, find a game, try it, and forget about it if you don't like it. Perhaps a better analogy would be a video file: you can download, watch, copy and delete it without having to install it.

User stories

  • Bob is developing a new music player. He finishes the first version, packages it, and puts it for download on his webpage.
  • Alice hears about a new music player and wants to try it. She finds Bob's webpage, downloads the software and tries it. As she finds it's good, she deletes her old one and copies the new one. She also makes a copy in her USB disk so she can use it anywhere.
  • Marvin is a virus developer that likes formatting other users' hard drives. He writes a multi-platform virus disguised as a P2P client, but he finds that on Ubuntu it simply does nothing.

Design

The exact implementation details should be decided by the community if this is approved, but here is the general idea:

The packages

The application files would be a standard package format such as tar, optionally compressed, containing everything the application needs to run. That means that an application includes all the libraries except the most basic ones, which would already be in Ubuntu (such as GTK, Python, libc, QT? ...). This will be seen by some as a waste of space, but since hard disk capacity is growing bigger and bigger, and software is usually not what takes most of it, we can afford to trade some for simplicity and usability; besides, most non-Linux OSs use a similar approach.

Inside this package there is: a configuration file (which states the name of the application, the developer, the version, and a webpage), the icon that will be shown in the file manager, a subdirectory containing the application files, and a subdirectory containing the current configuration.

Inside the first subdirectory there is an executable file or script with the libraries, data files, etc. The second subdirectory is a free space where the application can put whatever it wants (usually that will be configuration files or various extensions). By keeping things separate it's easier to reset an application to the beginning state in case of accident and almost impossible to break anything unless you want to.

Since the application will be moved from one place to another, the application must be designed to look for data only in these two folders, and always relative to the current location (i.e. look for ../data/config instead of /etc/config). Support for legacy or binary executables may be possible too (see below).

Overlay method

It is preferable to have the programs simply not access system folders, but that requires modifying the code and recompiling, which in some cases is too complicated or simply impossible. If that is the case for a given application, it could be put in overlay or union mode via the configuration file.

Overlaid software is similar to normal software except that the two subdirectories contain a full directory tree with the same structure as the application would have when installed. The two directories are then virtually overlaid on top of the filesystem for that process, so that any file that the application writes goes to the configuration folder, and any read returns the topmost matching file (see the image to understand it better). This makes the package transparent for the application and has the same results as the other method.

Security

Current Operating Systems' security is practically inexistent. Even with Ubuntu's sudo or Windows' UAC, it is still very easy for malicious executables to modify the filesystem or remove important files (that's why we need antivirus). The logical protection system would be that the Operating System controls every operation that an executable makes (such as modifying a file, connecting to the internet or accessing devices) and allows only the safe ones. There have been various attempts to do this, such as AppArmor, Plash, Bitfrost, Sandboxie and HP Polaris, but they either are only for MS Windows or are still not easily usable. An ideal sandbox would not allow applications inside packages to overwrite any system files outside its own directory. Other actions could be restricted, such as using too many resources, accessing the internet or even reading existing files without permission to prevent spyware. To allow the application to get write or read access to files (a text processor is useless if it can't save the text) the ideal way would be to intercept the standard file selection dialog and give access only to the file selected by the user. In that way, the sandbox would be completely transparent to the user.

Implementation

The Implementation would be hard. First it would be needed to decide the details, solve some problems and write a specification, and then develop the implementation.

Packages

This would be the easiest part of the implementation. To execute the packages would simply require to uncompress-mount the file somewhere (Compressed packages would be slower and generally desirable only for distribution. We could add a "Compression on/off" in the right-click menu), parse the config file to see if everything is correct, and execute the executable with the sandboxer.

Overlays

To overlay two folders aufs could be used to mount a union filesystem and chroot the program there (the sandboxing would still be necessary). The problem is that aufs does not allow to mount a filesystem over itself, so either patch aufs, work around it with some trick, or take a different approach (such as a new filesystem module).

Security

Here is the really difficult part: making a sandbox. However, it's not impossible, and it could actually be easier than making a driver for some device or some new notification daemon. Something simple like a chroot is not enough because it's impractical and there are other ways to do bad things than deleting files. My idea was to use a default AppArmor profile, perhaps modifying it when needed. There is a program called Plash that is designed for sandboxing, but it's not quite ready yet. The OLPC project used lightweight Vserver virtual machines. There are many other Linux security patches, and there is even a Linux Security Modules interface that could be used to make a new one. Otherwise it may be necessary to patch the kernel. It would also be necessary to patch the GTK library to intercept the file selection dialog, which would be easier. For a detailed analysis of a security system see http://dev.laptop.org/git/security/tree/bitfrost.txt

Migration

Migration would not be too difficult. A script that converts most .deb files into packages (using overlays) with little human intervention could be done, greatly simplifying the transition. After that it is only a matter of popularity and time to have programs designed for Ubuntu Security System. The only issue would be the fact that current Ubuntu desktops already have programs installed.

This system is not intended to replace .deb files and apt, it obviously does not work with system files, so synaptic would still be necessary. A new secondary official collection of applications could be hosted by Canonical. The "Add/remove" application would have to be modified to get applications from there too.

Unresolved issues

The first important issue are applications that need to modify the system to run properly. This most likely happens with applications that extend the system in some way (Windows example: FolderSize), or that need a special hardware driver (VMware?). General applications that do this are rare. The simplest solution would be to simply distribute them using .deb files instead of these packages.

The second issue is system integration. If a user is going to use a program as the main media player, (s)he probably wants all the MP3, OGG and AVI files to be opened by it, to have it in the menu bar or in the desktop... This could be done by another configuration file inside the package, defining the file extensions, menu entries and other things that may be associated. When the user selects the "Install" option from the file menu, the system reads this file and applies the configurations. To "uninstall" applications, the user opens the "Installed applications" window and removes or reorders the applications (it is important to be able to reorder the list because the user may prefer an application over another one, but may want the other installed because it can open more files).

Another issue is updating the applications, since there is no central repository. There are two possibilities: periodically visit an address specified in the configuration file to check for updates, or leave the upgrading process entirely to the applications and the user.

CategorySpec

ApplicationPackagingAndSandboxing (last edited 2009-08-29 16:08:43 by 202)