[apparmor] Learning apparmor

[John Johansen]

On 12/16/2012 08:11 PM, Diane Trout wrote:
> Hi,
> 
> I was trying to wrap a third-party application using apparmor and had a few questions.
> 
> (I was trying to wrap http://spectrum.im, I put my experimental profiles at https://github.com/detrout/apparmor-det)
> 
> 1) Are there common patterns for letting manager program control its children? As I was debugging the package it wanted things like "capability nice", and permission to look at /proc/child/statm. 
> 
hrmmm, yes and no. There are common patterns that do show up in linux especially among the toolkits/desktop environments. Eg gnome, gtk, kde, qte applications share some common patterns on how they do things.

> 2) to protect an application that has several seperate executables, does each piece need to be in a seperate apparmor file? e.g. usr.bin.manager and usr.sbin.daemon? or is there some way of using one profile?
> 
No, you are free to set this up in anyway that is appropriate for your needs/will work with how your applications are setup.

1. the profile file does not need to be named the same as the profiles it contains.
You can name the file what ever you want, the name is just a convention to help identify what it contains and also what some of the tools use when trying to generate profiles etc.

2. a profile file can contain multiple profiles
You can see this in the example evince profile. But it looks something like this

#include <tunables>

/profile/1 {
  ...
}

/profile/2 {
  ...
}

3. a profile can attach to multiple binaries, by specifying pattern matching in the attachment specification. In this case each of these applications are confined by the same profile

/attach/to/{binary1,binary2,binary3} {
  ...
}

doing this can result in ugly profile names so you can separate the name from the attachment specification

profile example_name /attach/to/{binary1,binary2,binary3} {
  ...
}

4. Once a profile is attached to an application the exec rules in the profile determine domain (profile) transitions.

ux - have the child go unconfined (not recommended)
  /usr/bin/app ux,
  /usr/bin/* ux,

ix - inherit the current profile, this can be used to keep multiple children apps in the same profile
  /usr/bin/app ix,

px - will use the profile attachment specification and application name to attach a profile
  /usr/bin/app px,  # attach to best profile by attachment specification (uses most specific before glob and longest left match if there are conflicts)

  /usr/bin/* px, # same as above but can result in different profiles based on the application name that is being execed

cx - like cx but use embedded children (local) profiles instead of the globally visible profile set that px uses

  /profile {

    /usr/bin/foo cx,

    #child profile
    profile /usr/bin/foo { }
  }

pix - same as px except, if no matching profile is found, it falls back to ix

px -> <name> - specify the profile to transition to

  /usr/bin/* px -> /profile,


In addition if there are overlapping exec rules the most specific is supposed to win

  /usr/bin/foo px,
  /usr/bin/* ix,

there is one major caveat with this, the compiler currently only supports this if
one of them is a specific (no pattern matching) match.
  /usr/bin/* px,
  /usr/** ix,

will be reported as an exec rule conflict at this time. This is something we would like to fix but there are higher priority items atm

> 3) if you've got multiple profiles, then can you put application specific shared pieces in apparmor.d/abstractions? Or is there some better way of sharing common permissions. (Like logging & reading config files).
> 
currently includes is really the only way of sharing common permissions.

You can update the current abstractions, or create new ones. In some situations it may be worth creating a variable, generally defined in tunables, and can be included as long as the include is in the preamble

apparmor variables are currently very limited, in that the can only be defined in the preamble (before any profile in a file). But they are some way like perl set vars.

eg.
@{example}=one two three

/profile {
  /foo/@{example} rw,
}

effectively expands into

/profile {
  /foo/one rw,
  /foo/two rw,
  /foo/three rw,
}