Docs/Security/AppArmor

From Apertis
Jump to: navigation, search

Contents

AppArmor system-wide policy guidelines

Background

The state of the art security in free desktop systems usually involves two main goals: not allowing users of the system to spy on other users' files and session and not allowing users or applications to obtain more privileges on the system than those originally intended. This approach leaves a very serious attack vector available: since an application is given the full access permitted to the user, it is also able to spy on all files, processes, and other resources available to the user.

In Apertis, the plan is to limit the system and the applications to the bare minimum which is necessary for them to work, while most sharing of information between applications will be over IPC. Applications will be able to control which pieces of their own data they want to share, rather than allowing other applications to read their files directly. This is to be implemented in a white-list fashion where everything is denied by default, and any permissions required by the application can be granted and inspected/validated by the curator of each application store, normally the OEM.

How

The white-list approach is to be implemented by having a profile for the application launcher that denies everything for child processes, forcing them to have profiles of their own. A number of abstractions will be provided to provide access to resources every application should be allowed to use, and to provide broad sets of permissions, in such a way that profiles for applications be more readable and easy to create. Abstractions are AppArmor profile snippets that can be included by an application's profile.

The default rule-set is provided by the sac-base abstraction, provided by the sac-apparmor-profiles package.

Profile transitions

One of the foundations of our AppArmor strategy is to use the fact that we know what the process tree should look like, and use that knowledge to apply specific policies. For instance, the system has several separate D-Bus sessions: a system one and a session one per logged in user. We can create a profile for the system D-Bus daemon and a profile that only applies to the D-Bus daemon started by the Xsession, by making it a child profile.

That is also the strategy which we are adopting to provide a deny everything capability and allow a specific policy: a very restrictive policy is applied to the application launcher and forces all processes initiated by it to inherit the launcher's restricted policy unless it has a specific profile.

User Session lockdown

In order to implement a full session lock down, a profile is needed for all the processes in the process tree:

With all recent releases, the user session managed by systemd looks like the following:

User-session.png

Profiles involved in session lockdown

The main package providing the session lockdown profiles is sac-apparmor-session-lockdown. It ships with the following main profile definition files:

  • usr.bin.X
  • usr.bin.Xorg
  • usr.session-startup

The usr.bin.X and usr.bin.Xorg files have what you would expect: allowing everything X needs for running properly, including accessing devices and managing consoles. The profile file usr.session-startup contains the profiles for the core components of user session: mutter (x-window-manager) and the accessiblity-related at-spi daemons. Note that the profile for the dbus-daemon launched by the accessibility daemons is as a child profile. See Profile transitions above for more information on how using child profiles helps us.

The other services in the session startup ship with their own AppArmor profiles, and are confined using them. Currently, due to a limitation of AppArmor, the DBus Session Bus is not confined.

While it's not shown in the above image, the app launcher (which is being worked on and is currently not present in our images) has also been confined, and is tested using a very simplistic placeholder launcher to test, validate, and demonstrate the concept. Said launcher is shipped in the sac-apparmor-test-launcher package along with its AppArmor profile and an accompanying profile for the MxLauncher test browser used to test webkit-clutter. The launcher is automatically started upon session startup, if installed. A simple text entry allows running arbitrary commands to test that the lockdown is being applied properly.

Testing the lockdown

The best way to test that the lockdown is currently working well is to look at the logs and by running the tests.

Default profile

It's a common scenario having a privileged process which has its own AppArmor profile and needs to spawn some children processes. Usually a profile would use a "Pix" rule to define a transition, but since it's a privileged process, it's not a good idea to allow a child process to inherit the privileges the parent process has.

Think about a process which runs as super user, which spawns another process.

We don't want that any child process, which not have a profile itself, inherits the rules which have been built for a privileged process (which can access several critical resources, for instance a camera device).

What we want instead is that any child process which has no own profile is contained in a smaller profile, much more restricted and safe than the parent/privileged one.

This is obtained by the abstraction/sac-helpers, specifically the subprofile sac_sanitized_environment.

A good example of how it can be used is in the profile /etc/apparmor.d/abstractions/dbus-daemon which uses it; specifically it's used for defining how the services run by dbus-daemon will be contained.

Personal tools
Namespaces

Variants
Actions
Navigation
Tools