path: root/security/apparmor
Commit message (Collapse)AuthorAgeFilesLines
* AppArmor: functions for domain transitionsJohn Johansen2010-08-022-0/+859
| | | | | | | | | | | | | | | | | | | | | | AppArmor routines for controling domain transitions, which can occur at exec or through self directed change_profile/change_hat calls. Unconfined tasks are checked at exec against the profiles in the confining profile namespace to determine if a profile should be attached to the task. Confined tasks execs are controlled by the profile which provides rules determining which execs are allowed and if so which profiles should be transitioned to. Self directed domain transitions allow a task to request transition to a given profile. If the transition is allowed then the profile will be applied, either immeditately or at exec time depending on the request. Immeditate self directed transitions have several security limitations but have uses in setting up stub transition profiles and other limited cases. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: file enforcement routinesJohn Johansen2010-08-022-0/+674
| | | | | | | | | | | | | | | | | AppArmor does files enforcement via pathname matching. Matching is done at file open using a dfa match engine. Permission is against the final file object not parent directories, ie. the traversal of directories as part of the file match is implicitly allowed. In the case of nonexistant files (creation) permissions are checked against the target file not the directory. eg. In case of creating the file /dir/new, permissions are checked against the match /dir/new not against /dir/. The permissions for matches are currently stored in the dfa accept table, but this will change to allow for dfa reuse and also to allow for sharing of wider accept states. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: userspace interfacesJohn Johansen2010-08-024-0/+455
| | | | | | | | | | | | | | | | The /proc/<pid>/attr/* interface is used for process introspection and commands. While the apparmorfs interface is used for global introspection and loading and removing policy. The interface currently only contains the files necessary for loading policy, and will be extended in the future to include sysfs style single per file introspection inteface. The old AppArmor 2.4 interface files have been removed into a compatibility patch, that distros can use to maintain backwards compatibility. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: dfa match engineJohn Johansen2010-08-022-0/+485
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: contexts used in attaching policy to system objectsJohn Johansen2010-08-022-0/+370
| | | | | | | | AppArmor contexts attach profiles and state to tasks, files, etc. when a direct profile reference is not sufficient. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: basic auditing infrastructure.John Johansen2010-08-022-0/+338
| | | | | | | | Update lsm_audit for AppArmor specific data, and add the core routines for AppArmor uses for auditing. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* AppArmor: misc. base functions and definesJohn Johansen2010-08-024-0/+491
Miscellaneous functions and defines needed by AppArmor, including the base path resolution routines. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>