AppArmorNamespaces

From AppArmor
Jump to: navigation, search

Required Versions

  • AppArmor 2.3 with 2.6.??? kernel
    • Limitations
      • Limited experimental flat namespace support. Only partially like documented here
  • AppArmor 2.5 with 2.6.??? kernel
    • Limitations
      • Hierarchical namespaces, no stacking, basic creation/deletion via profile load and removal
      • View == current namespace
  • 2.11 with AppArmor 3.5-beta1 - (Ubuntu 16.04)
    • Limitations
      • View == current namespace
      • stacking is buggy without backported patches
      • No mkdir/rmdir namespace interface
      • apparmor/policy is not virtualized
      • /sys/module/apparmor/parameters/* are not virtualized
  • 2.11 with AppArmor 3.6-beta1 - (Ubuntu 16.10)
    • Limitations
      • View == current namespace
      • apparmor/policy is not virtualized
      • /sys/module/apparmor/parameters/* are not virtualized
  • AppArmor 4
    • Limitations
      • In development


AppArmor Policy Table of Contents

AppArmor Policy Namespaces Table of Contents

Introduction

AppArmor policy namespaces allow separating AppArmor profiles in to different logical groups that provides a scope for the profiles, names, variables and attachments inside of it. In addition they provide for control over profile management and are the basis of how confinement is viewed.

Attributes of a policy namespace

Each policy namespace provides a set of profiles that can be applied, a unique unconfined profile, a default profile, a unique set of variables, and a set of controls for who can manipulate the namespace.

name

Each policy namespace has a name consisting of alphanumeric chararacters and begins and end with a :. Technically the beginning and ending colons (:) are not part of the name but a prefix and separator but the name will always be shown with the colons so as not to confuse them with profile names.

eg. :namespace:
    :jail1:

The namespace name when combined with a profile name is known as a fully qualified path which is done by concatenating the profile name to the namespace name with the prefix and suffix : affixed with an optional separator between.

eg. :namespace:profile_name                # ssh style
    :namespace:/profile/name               # ssh style
    :namespace://profie_name               # url style ie :// as separator
    :namespace:///profile/name             # notice /// always parses as the separator (//) first then /
    :namespace://profile//child            # fully qualified name of a child profile

The maximum length of a name is undefined but it is recommended to keep them short as they will often appear with profile names in a fully qualified path, and different parts of the system have hard limits.

 Eg.
 The proc interface used for introspecting tasks is limited to a PAGE_SIZE
 Cipso labeling for networking is limited to 40 characters
 ...

Why do namespace names need to begin with a :

When AppArmor profile names are used as an attachment can have any character or pattern that a file name may have. This greatly limits how namespace names can be expressed. Non-attaching profile names also put their own constraints on how the namespace name can be expressed. Because of these limitations a unique leading character is used to indicate the beginning of a namespace name. The same technique is also used to indicate and instances, stacks, delegation, and variants.

The trailing : with optional separator // separates the namespace name from the profile name using thes common separators from ssh and several protocol urls.

unconfined profile

Each namespace gets its own unique unconfined profile that is used to track task assigned to the namespace when they are not confined.

default profile

Each policy namespace has a default profile that is assigned to tasks when no other profile in the namespace has an attachment that matches. The standard default profile is the unconfined state. Each policy namespace has its own unique unconfined state profile which is used by tasks assigned to or created within the policy namespace.

Note: as of AppArmor 3.5 setting the default profile to something other than unconfined is experimental and can only be applied to the root system policy namespace, via a grub kernel parameter.

variables

TODO

controls

TODO

Referencing profiles and profile transitions within a policy namespace

???

Policy Namespaces are Hierarchical

AppArmor policy namespaces are arranged in a tree structure with the system policy namespace at the root. The system policy namespace can have children namespaces, which in turn can have their own children. Like profiles names, namespace names can be expressed as a path using // as a component separator.

 Eg.  :parent//child:
      :parent//child//grand_child:

Policy Namespace names are Relative to the View

AppArmor policy is authored and introspected from the point of view of a task' confinement.

When authoring policy

When a profile specifies a profile (or label) without specifying a namespace the reference is relative to the namespace the profile is in. That is given

 :ns1://A
 :ns1://B
with profile :ns1://B having the transition
px /** -> A,
the profile A referenced is for the profile :ns1://A

When a profile specifies a profile (or label) with a namespace prefix the name is always relative to the namespace view.

When viewing policy

When viewing a task's confinement, the name reported will always be relative to the namespace view. If the view namespace of the target is the same as the task doing the viewing then the namespace name will not be reported. If the namespaces differ then visibility and view virtualization considerations will be enforced (see view and visibility).

Policy Namespace Visibility

Policy Namespace visibility is determined by the namespace view, and namespace Hierarchy. Parent Namespaces can view their descendants (children, grand children, ..). However the full namespace hierarchy may not be visible to all tasks, descendant namespaces may or may not be able to view parent or sibling namespaces dependent on the namespace view.

Further discussion of visibility will occur in the section on namespace views.

Profile transitions between namespaces

????

relative vs abs ns path

root ns is not express via a name

ns: refers to a namespace within the current root ns



When View is not the current namespace

In AppArmor 4 it is possible to have the view be a namespace that is different from the current namespace. When this occurs the view will be an ancestor of the current namespace, and the view will affect what profiles and namespaces are used when directly referenced.

For transitions and management when no namespace is specified the current namespace is used If a namespace is specified then it is from the view

:: is the namespace of the view
No equiv of file path ..
If you want the root of the view, or ns that is not a descendent the must specify abs path for view root 

how to do relative vs abs ns path

Simulating flat namespaces by setting the view

While AppArmor namespaces are hierarchical they can simulate a flat set of namespaces by setting the view to the parent namespace of the set of namespaces that should appear to be flat. Since references to namespaces are relative to the namespace view all first level children of the view namespace are referenced by a single level name and appear like a flat namespace set.