AppArmorObjectLabeling

From AppArmor
Jump to: navigation, search

AppArmor Policy Table of Contents

AppArmor Object Labeling Table of Contents

Introduction

AppArmor is a variant of DTE and as such most objects typing or labels are derived from the domain (profiles) rules, instead of being explicitly stored on the object.

blah, blah, blah

Definitions

  • domain: the set of profiles that defines a subjects confinement. It may be a single profile or a stack.
  • domain/subject label: the label on a subject or proxy
  • domain/subject type: The domain/subject type is derived from the domain label, allowing for permission lookup without computing conditionals
  • explicit label: a label that is explicitly stored on an object
  • implied label: an object label that is found from the set of profiles that can access the object.
  • label: a unique name used by policy to help identify confinement.
  • object: A resource, file, record, message, .., that a subject interacts with.
  • object label: the label on an object.
  • object type: The object type is derived from the domain label and object label resulting in a reference that can be used to compute object access permissions without computing conditions.
  • profile: The profile is a label with rules and is the base unit of task confinement in AppArmor. Each profile has a unique name, some control flags, and a white list that defines the sets of rules and relations that govern what permissions a task will have.
  • proxy: A task or object that is acting on the behalf of a subject. It uses the domain/subjects label to determine the set of rules to enforce.
  • subject: An active entity (task/process) or a proxy for a task/process. The labeling on a subject determines the set of rules being enforced.
  • stack: a set of intersecting profiles that define a subjects confinement.
  • type: a value that can be used as part of a tuple to lookup permission. <subject type, object type> -> <permissions>

Implied object labels

The profile(s) on tasks is know as the domain label. When the task is treated as an object its label is used as the object label. If the task is confined by a stack of profiles the label is the stack is the same as the domain intersection used in the first type example.

 eg.
   profile A {
       file r /abc,
   }
profile B { file w /abc, }

which can be expressed in type enforcement as subject | Implied label ---------+--------------- A | A&B B | A&B

When an object is created without an explicit label it will use the creating tasks label as its object label.

Domain object labels on sockets are used as proxies for the set of task that the socket is shared by.

Derived Object types

If an object does not have an explicit label, the label can be computed from the set of profiles that have permission to access the object. The simplest derived object type is the same as the implied object label.

 eg.
   profile A {
       file r /abc,
   }
profile B { file w /abc, }

which can be expressed in type enforcement as subject | object type | permission ---------+-------------+------------- A | A&B | r B | A&B | w
The object type is the intersection of the two domains that have access to the objects.

With more rules the intersections of domains is not enough to express the object type and the domain portion of the type must be split

 eg.
   profile A {
       file r /abc,
       file w /bc,
   }
profile B { file w /abc, file w /bc, }
requires splitting the domain types further ---------+-------------+------------- A | A_r&B | r A | A_w&B | w B | A_r&B | w B | A_w&B | w

Further rules will result in further domain splitting to derive the type.

explicit object labels

The derived (implied) object type covers base typing for the system but is not sufficient to provide proper isolation especially in situations like shared directories like /tmp/. Where all profiles will include rules to access the tmp directory.

 eg.
   file rw /tmp/**,

In these situation DTE stores a type or label on the object (or in a side db) that overrides the derived type. AppArmor takes advantage of the security xattr namespace to store an object label, not a type. AppArmor uses an object label instead of a type to better integrate object typing with how ???


object label rules

rules can be conditional on the explicit object label

 file r label=X,      # any file with the label
 file r label=X /bin/**,  # any file in /bin with the label
 px label=X /bin/** -> foo,
 px label=X /bin/**,
 # task receives domain label B if exec file has label=Y and it is at path /bin/foo
 profile B attach=(label=Y path=/bin/foo) {
 }


setting an explicit label

The explicit label can be set either directly via an application setting the security.apparmor xattr or via policy

directly setting the xattr

To set the security.apparmor directly an application requires sufficient permission

 profile rule examples ???
 writing to the label can be dependent on the current label

the label will only be set for the applications namespace scope, or if a child namespace is specified it may be set for that

 eg.


what happens to the existing an existing label

 over written if the application is allowed access


the label written can be a stack

policy rules

 file w label=X /**  label:=Y,


limits on when the label can be set

domain transition rules & attachments

- profile rules match first, once matched then

 - named transition: transition to named profile
 - unamed match exec name, label (even if used in rule) to profile attachment
   - so label must match in rule and profile attachment

stack

multiple profiles on a task

how this works as a label

how to determine the label when stacking and a rule sets a label

NS labels

labels don't eval across policy namespaces

??? dfa

how userspace resolves overlapping rules to detect conflicts, and ensure only a single label can be set for any partition.

how creation minimization provides single partition per type in profile.

Why apparmor uses object labels instead of type

object label is a proxy for task domain label in msg receive which is not done in task context

Many objects are implicitly labeled by their creating task(s) label if an explicit label is not specified, having an explicit label instead of type matches the use of the implicit domain label. Even file implied objects domain labeling could be computed by taking the intersection of all profiles that can access the file.

Using a label provides better flexibility allowing for conditions around path, fstype etc

layout encoding of label conditional