| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow broken Lucid userspace tools to load policy, on Maverick kernel.
The fix for http://launchpad.net/bugs/581525 blocks Lucid tools from
loading policy, this provides compatibility with Lucid tools without
reintroducing the bug.
The apparmor_parser when compiling policy could generate invalid dfas
that did not have sufficient padding to avoid invalid references, when
used by the kernel. The kernels check to verify the next/check table
size was broken meaning invalid dfas were being created by userspace
and not caught.
To remain compatible with old tools that are not fixed, pad the loaded
dfas next/check table. The dfa's themselves are valid except for the
high padding for potentially invalid transitions (high bounds error),
which have a maximimum is 256 entries. So just allocate an extra null filled
256 entries for the next/check tables. This will guarentee all bounds
are good and invalid transitions go to the null (0) state.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
| |
|
|
|
|
|
|
| |
move LSM-, credentials-, and keys-related files from Documentation/
to Documentation/security/,
add Documentation/security/00-INDEX, and
update all occurrences of Documentation/<moved_file>
to Documentation/security/<moved_file>.
|
| |
|
|
|
|
| |
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
|
|
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>
|
