AppArmor mediation is based around the profile, which is a named
set of rules that are applied to a task (application). ??? variety
of rule types??? file, network, ipc, capability, rlimits. ??? Not a
set mathematical model???
AppArmor mediation is Applied in addition to DAC and can
not override DAC checks. When AppArmor is combined with
pam_capability? capabilities can be granted which can override DAC
checks and then AppArmor further restricts.
AppArmor internal permissions
AppArmor defines a set of internal permissions that is different than
represented in policy.
why no trunc? - minimal value - changing the size of the file,
would allow catching some behaviors but doesn't stop a task from
destroying data. If a task can write to a file it can overwrite the
file with garbage.
mv/cp are equivalent, mv doesn't result in a different labeling than
cp. ?? will this remain true for on disk labels??
why no mv/rename permission? Coould be used to enforce where files
can be renamed. Eg. rename /foo to /bar, - in reality it has minimum
value as it can not be generically enforced from the kernel. renames
within a fs/device/partition could be mediated this way but renames
across devices are handled as copies. Where the kernel can't “see”
the connection of reads and writes being done by user space. Thus a
copy could in many cases be used to circumvent a rename rule. A rename
rule could be useful in forcing the behavior that a file is created in
one part of the file system/device and only ever moved. Ie standard
creation and write are not allowed at the destination, but a rename
is allowed (but his would break copying to the location).
mapping policy based permissions to internal permission - this is
done is ideally done in the parser, but can be done in the loading
interface to provide backwards compatibility with older versions of
Enforcing Permission Mapping
AppArmor kernel module is a policy engine, the LSM is considered as
AppArmor does not provide a one to one mapping of DAC permissions to
A permission request is done by mapping LSM functions and parameters
to an AppArmor permission set.
File object mediation
AppArmor file object mediation is path based but has been slowly
evolving towards a hybrid of path and label mediation. Currently
AppArmor's uses DAC labeling of files (owner of file, ...) as a
secondary condition beyond path name to determine access rights. Using
xattr based labeling as another condition is possible and AppArmor
will be extended to use them in the future.
rules order independent To determine access permissions to a file ???
Once file access rights are determined opened file descriptors are
labeled with profile that they were opened under (dynamically labeled,
note this label is not written to disk). This labeling is then used
as the primary label for the lifetime of the file descriptor even if
the on disk file object is moved (AppArmor does not do any revocation
at this time). Any further access checks for the file descriptor are
done against the primary label and if this fails, then a secondary
revalidation check against the files current name can be done to
determine access rights.
revocation/revalidation - at exec time, reload of profile, change_hat
AppArmor uses the path of file objects based mediation as part of its
controls. The path of the obPaths are used at open and to revalidate.
label open files with profile that opened them - delegation
revalidation and change_hat
AppArmor path rules from a labeling perspective
There are two ways to think of AppArmor file rules as labels, either
the path as the label or unique dfa accept states as a label.
Path as a label
The path can be thought of as a label - multiple labels per file
Dfa state as label
The best equivalent AppArmor has to a label would be the unique accept
state in a dfa. - can intersect profiles to find shared states (labels)
can analyze total policy this way
when a file object is accessed that has not been delegated and
has not been labeled to match - Relooks up path, treated like
opening file at that instant
Mediation without the path
network rules - labeling via profile (sid)
AppArmor capability rules allow selective access to a tasks capability
Extended capability rules
The extended capability rules allow further restricting what is
granted by a capability. Each rule has its own syntax.
Conditionals on owner, user, profile, file type
# only allow dac_override on objects belonging to user1, or user2 this include file and ipc # conditional capabilities are scheduled for apparmor 3.0 owner=(user1,user2) capability dac_override,