Application Confinement

If we increase the number of application from third parties available to end users then the number of applications that can harm the user will increase.

Classification

Intent

We can split apps in to two categories based on the intent of the developer:

1. Malicious, either to damage the machine, use its resources, or transmitting the users data elsewhere due to malicious intent on the part of the application developer.
2. Inadvertent, doing the same things as above but due to unexpected bugs or compromise of the application.

The effects are similar, but the distinction is useful, as the developers of the apps in the latter case are likely to be willing to confine their applications according to expected functionality, whereas the former developers will attempt to circumvent any protections, and not voluntarily allow their app to be confined such that they can't achieve their aims.

Aim

We wish to build a system that reduces the threat to Ubuntu users due to applications, so that they can be confident in using their system, and don't have to spend time cleaning up after malware.

This protection can take two forms:

1. Protection from malicious apps. If an application is confined such that it is unable to do the malicious thing that it is designed to then it is protected.
2. Protection from inadvertently dangerous apps. If the application is contained such that it can't do things that are not necessary for its desired functionality then the chance of problems is reduced.

Assumptions

• Any system is not going to be complete unless we carefully review every line of code submitted, and we aren't going to be able to do that (and indeed we don't today with new packages entering Debian/Ubuntu.)
• We will have a system to flag problematic apps for review, and the ability to remove these apps from Software Center (in such a way that the app isn't forcibly removed from users systems, but such that most users will have it removed soon after doing so.)
• We will not present a list of things that an app can do to users at install time, or on first run. However, we should allow users to opt in to seeing these (and ideally edit them) so that we can get review from power users.
• We can't completely confine every application, as there are very few useful apps that can work in such a situation. (I'd love to be proved wrong on this, and to institute a default-deny policy.)

  • jdstrand: IMHO this is overstated. It is not desired to tightly confine applications, but practical confinement (ie one that protects the system from (varying degrees of) harm while still allowing the application to be useful) can be provided for nearly everything

• We can't leave this up to third party developers entirely because:
  • The separation between third-party apps and Ubuntu isn't very clear to end users (some user-testing of this would be great)
  • We take some responsibility for the experience of Ubuntu users, and so we would like to ensure that they are secure on Ubuntu, even if they use third-party code.

Design

Confining non-malicious apps

In the case where the developer isn't malicious, we can ask for their assistance in confining their application.

They should be able to choose a list of capabilities that their app requires, and anything not chosen should be denied to the app. They can then test that everything still works ok under this policy before pushing the app for review.

In order to encourage people to do this it should cause their apps to be reviewed quicker. In the extreme case of a "deny everything" policy their app should move immediately through the process as possible harm to the system is very limited. The exact details of what should trigger more review are still to be worked out.

• jdstrand: To restate, when people provide confinement, reviewers can start by reviewing the confinement policy and potentially look at only those areas in the application that are a concern (eg, if file access is restricted, but it allows network access, can potentially just review the networking bits)

Confining malicious apps

Given the the application author is malicious they won't choose to remove capabilities from their applications that are needed in order to perform the intended task.

However, we can use the above system as a way to help point out the apps that need more review. If an app needs something that doesn't seem necessary from its stated purpose then it's ripe for review.

jdstrand: The confinement policy tools should make it easy for reviewers to apply policy to software that is submitted without a confinement policy. The act of using the policy tools and examining their output can provide clues to the nature of the application (at an easier to understand level than strace or the like). If the application runs as intended with the policy used in the review process, it can be applied to the packaging as part of the acceptance process.

Unanswered Questions

• Can we have a capabilities system that is coarse enough for third-party developers to use, but fine-grained enough to allow selective reviewing?
• Do we even have enough review time to review the smaller set of apps that need dangerous capabilities?
• What is our threat model for apps? Can we design a system to deal specifically with that threat model?

Implementation

There are two technologies that would be particularly interesting for an implementation of ideas like these:

• AppArmor

  • jdstrand: Work for 12.04 will include an easy to use profiling tool to develop AppArmor policy. This will be implemented as a python library so the ARB tools, developer.ubuntu.com SDK, arkose and any other tools can easily import it. The options will take cues from arkose' interface. May also include a GUI tool that people can use. The process for developing a profile or using the tool as part of the ARB review process will be documented in easy to understand terms.

    • jdstrand: aa-easyprof is implemented and included in Ubuntu as part of the apparmor-utils package. Please see the AppArmorEasyprof specification for more details and documentation on how to use it.

• arkose (see blueprint from UDS P)

However a specific implementation plan is not included here, as the design is not fleshed out sufficiently.