[apparmor] Learning apparmor

[John Johansen]

On 12/18/2012 09:31 AM, Diane Trout wrote:
> Thank you for the quite detailed response to my first questions.
> 
> Can you have overlaping rules in one file?
> 
within a profile overlapping rules have their permissions merged for
the parts of the rules that overlap, except for exec qualifiers where
the most specific one is chosen.

Also apparmor rules are declarative so that order does not matter.

Oh and I suppose I should mention the deny prefix while I am at it.
You can specify deny rules that remove/ensure certain privileges
are not granted. Deny rules take precedence over allow rules and
can be used to remove permissions from a broad allow rule.

eg.
  deny /etc/shadow rw,
  allow /etc/* r,

> e.g.
> 
> profile spectrum-common /usr/bin/{spectrum2_manager,spectrum2} {
>   # acccess config file
>   /etc/sepectrum2/** r,
> }
> 
> # manager should be able to launch children
> /usr/bin/spectrum2_manager {
>   /usr/bin/spectrum2 rm,
> }
> 
> #daemon should access net
> /usr/bin/spectrum2 {
>   #include <abstractions/nameservice>
> }
> 
> If given that, would the spectrum-common rules apply to both?
> 
Sorry, this is not supported currently. You would need to make an
abstraction to share the rules.

> I'm also assuming that if there's a way to use it ix is also a good choice. (Especially if I want to wrap my pbuilder jobs). 
> 
yes, ix is a good way to just right a generic profile. It is often
used to do things like confine shells.

> Is there a more detailed explanation of the between P and C modes?
> 
P/p - search for a profile in namespaces list of profiles
C/c - search for a profile in the current profiles local list

The namespaces list of profiles is the set of profiles that are
checked against when an unconfined application execs an application.
In fact you can think of unconfined having the following exec rule
  /** pix,

where if it doesn't find a matching profile it allows the exec,
inheriting the unconfined profile.


The profile local list is never used unless specified by C/cx
and allows for a profile to have custom helper profiles.
Eg. Firefox may have a helper profile for evince that is different
    than the system evince profile.

The difference between P/p, and between C/c is that
P/C - cause the secure exec flag to be set, which will cause glibc
      to remove some environment variables (eg. LD_PRELOAD).
      But others will not be touched (eg. PATH).

      I am not aware of a complete list of the environment variables
      that get touched beyond the glibc code it self.

      Note: this also relies on the linked C lib to actually do
      the clearing during early start up, if the application was
      linked against a C lib that doesn't support this then there
      is no difference between P/p nor C/c.

p/c - do not set the secure exec flag so glibc should not do any
      environment scrubbing.

P/C - are the safer options but sometimes wrapper scripts set
      environment variables to launch an application in a specific
      way, and they can break the scripts.

      Firefox used to do this and might still


> The man page implies both require that there is a profile defined for the subprocess. One requires a profile, one requires a "local" profile.
> 
Right, what this means is that the exec is failed if Px, px, Cx, cx,
do not find a profile that matches.

If you want an exec to succeed regardless of whether a profile is
present you need to specify what to do for a fallback, which is either
i - inherit
u - unconfined

so Pix, pix, Cix, cix, Pux, pux, Cux, cux