AppArmor 2.6

conditionals based on file type ie. can make creat condition on node type

kernel variable tables for conditionals

extended capabilities

chroot

chown

ptrace

setuid

in match rule dynamic variables /proc/@{PID}/foo

delegation

improvements to parser

improvements to user tools

tunables

aliases

profile namespace support

improve notification mechanisms

how to handle cap and network address family number mappings

testsuite

log auditing

kernel auditing

also search supplementary groups in pam_apparmor

AppArmor 2.7

Tools

Parser

replace/cleanup front end

split into separate tools

common parsing library

common computation library

common interface (loader) library

compiler

loader

verifier/analysis tool

New tools

profile merge tool

gui profile editing tool

gui control tool (init script interface)

new learning tools (replace genprof/logprof)

terminal (ncurses)

gui

static binary analysis for profile generation

sandbox generation tool

basic profile setup

(autodep + default rule set)

load profile

setup jail

chroot (no sharing)

union fs/mount + bind mount

share data (control reads with rules)

capture writes

Notification

OSD

system bus

direct to user session bus

way to kick off profile update tool

email, ...

aa-confine - run cmd confined by a <profile>. If <profile> does not contain permissions to exec <cmd> then the exec will fail. The profile used must already be loaded in the system unless a template is specified with -t. Eg:

aa-confine guest_user ls -l /home

aa-top - watch apparmor profiles

aa-ls - list file confinement (profiles/permissions)

Front End (User space)

Features that are can be completely implemented in user space with current backend

x dominance analysis - allowing for overlapping x rules

pcre based rules (expose more matching ability)

rule subtraction or some such allowing for more expressive rules

Back End (Kernel)

The back end (kernel module) exposes to the front end a set of features, that the front end then maps to and leverages. As such the back end doesn't generally have new features that can be implemented separate from the front end. There are however general cleanups that can be done in the work items list.

No blockers for moving upstream Linux. Have commitments it will go in once all issues are addressed. Work is ongoing and pushed upstream for (re)review. Inclusion is 2.6.36 is expected.

BSD kernel backend? Is it possible, is it desirable. Would be a new implementation.

verify/deal with btrfs snapshots

Language/features improvements

new language - possibly move to a new language?

separate out x rules from others

remove m?

permissions come before filenames?

direct learning connection to kernel (netlink)

multiple names for a profile (extend upon regex profiles)

profile aliasing - share profile from different namespaces etc.

delegation

kill rules

extended conditionals rules

extended capability mediation

dynamic loadable variables

per namespace

per user

per profile

user definable profiles

networking

stage1 socket, outbound control

table based rules

labelled packets handled by ipc

ipc

per ipc type control

generic passing of info from/to domain

labelled network communication

mount mediation

chroot (improvements to chroots are handled)

disconnected paths

filesystem namespaces (bind mounts)

keys

regexs in includes (e.g. include <dir/*.conf>)

Documentation

update techdoc

wiki cleanups

policy language document

bring man pages up to date

Resource usage improvements

Policy memory usage and computation time (high)

Ideas

could improve with table compression

better memory usage, speed improvements

need to evaluate different methods, potentially switching away from a strict DFA

need to cache the metadata about the on-disk profiles used to generate a cache

sharing the parser's internal state when generating multiple profiles that share common abstractions

cuts down on memory usage (~50%) and compile time

needs some parser changes

atomic multiple profile load (low)

currently doing 1 at a time, want to load multiple at once (isomorphs generated during multi-profile parsing)

start with profiles with subpolicies like firefox and evince

Convert to default chroot relative profiles

AppArmor 3.0 will move to using chroot relative profiles by default. This means that profiles will resolve names relative to the chroot rather than relative to the namespace.

Goals

remove use of kernel ability that may be removed

Unify handling of chroot and fs namespaces from a policy pov

Deal with the disconnected path problem

provide backwards compatibility via flag etc while policy is migrated

Rational

chroots in the past were handled in a namespace relative manner. That is the chroot location is prepended to the path name. This is problematic for several reasons.

The ability to find this value may be removed at some point. If this goes away we currently don't have a good fix because of how policy is structured.

The profile names are not what are visible to the application

profiles used within a chroot are tied to a specific location, and thus not reusable for other locations ie. the prefix that is the chroot location that is appended to every rule

profiles intermix pre and post chroot rules

may give post chroot application more privilege than necessary

may give post chroot application access to files outside of the chroot

chroots are handled differently than filesystem namespaces. Filesystem namespaces are similar to chroot in concept except there is no way to get the fs location like there is the chroot location. Thus they need a different solution. Ideally chroot and fs namespaces should share a common solution for profile sanity

namespace relative chroot profiles don't work for profiles loaded within a chroot (ie. the chroot is a container virtuallizing an OS)

Profile stacking means that multiple profiles maybe applied to a single access request. There is a need to minimize path lookup operations which means restructuring the path code, and sharing a single path between all profiles.

Solution

Make profiles chroot relative - this mimics what happens with fs namespaces

Use labeling to handle files that are passed in and would result in a disconnected path

Use profile and namespace transitions to separate pre and post chroot policy. This structural changes allows profiles to contain just what is necessary pre and post chroot. It also allows better simulation of the current namespace relative behavior

Use namespace_relative profile flag for backwards compatability where necessary

Use kernel variables on the security context to store chroot location to allow continuing to offer "namespace_relative" compatibility

Problems

With chroot relative paths, paths outside of the chroot but in the namespace are still disconnected. Many chrooted apps have files that are opened and then past into the chroot. This needs a labeling or other solution

breaks current applications using chroot and profiles

breaks current unconfined behavior. System profiles are applied to applications run from within the chroot.