attachment specification doesn't contain globbing.
eg.
# profile name and attachment the same - attaches as expected
profile /usr/lib/chromium-browser/chromium-browser
# profile without attachment specification - does not attach as expected
profile chromium-browser
# profile with name and attachment specification where the attachment specification uses globbing - attaches as expected
profile chromium-browser /usr/lib/chromium-browser/chromium-broswer*
# profile with name and attachment specification without globbing - FAILS to attach when it should
profile chromium-browser /usr/lib/chromium-browser/chromium-browser
This occurs because the xmatch_len is not set correctly for the profiles that specify
a name and an attachment specification, where the attachment specification does not
contain globbing characters.
In this situation the correct length for the xmatch_len is the length of the name, as
the shortest possible unambiguous match is the name length.
This patch does not fix a related bug where an attachment specification of ** will not
match (/**) will.
Add the ability to specify the name and attachment of the profile
separately. It does not allow for the attachment specification to
begin with a variable however since variables in profile names is not
currently support this shouldn't be and issue.
Signed-off-by: John Johansen <john.johansen@canonical.com>
commits were made (as well as a few other minor warnings elsewhere).
The Makefile change is to avoid passing -Wstrict-prototypes and
-Wnested-externs to the C++ compiler, which the compiler yells about and
then ignores.
Since we compile with -Wmissing-field-initializers I dropped the
unreferenced zero-width fields in the header structs, and then explicitly
initialized the remaining fields.
I tagged several unused function parameters to silence those warnings.
And finally, I dropped the unused filter_escapes() too.
tree. It is limited in that it doesn't currently handle the permissions of a rule.
conversion output presents an aare -> prce conversion followed by 1 or more expression
tree rules, governed by what the rule does.
eg.
aare: /** -> /[^/\x00][^\x00]*
rule: /[^/\x00][^\x00]* -> /[^\0000/]([^\0000])*
eg.
echo "/foo { /** rwlkmix, } " | ./apparmor_parser -QT -D rule-exprs -D expr-tree
aare: /foo -> /foo
aare: /** -> /[^/\x00][^\x00]*
rule: /[^/\x00][^\x00]* -> /[^\0000/]([^\0000])*
rule: /[^/\x00][^\x00]*\x00/[^/].* -> /[^\0000/]([^\0000])*\0000/[^/](.)*
DFA: Expression Tree
(/[^\0000/]([^\0000])*(((((((((((((<513>|<2>)|<4>)|<8>)|<16>)|<32>)|<64>)|<8404992>)|<32768>)|<65536>)|<131072>)|<262144>)|<524288>)|<1048576>)|/[^\0000/]([^\0000])*\0000/[^/](.)*((<16>|<32>)|<262144>))
This simple example shows many things
1. The profile name under goes pcre conversion. But since no regular expressions where found
it doesn't generate any expr rules
2. /** is converted into the pcre expression /[^\0000/]([^\0000])*
3. The pcre expression /[^\0000/]([^\0000])* is converted into two rules that are then
converted into expression trees.
The reason for this can not be seen by the output as this is actually triggered by
permissions separation for the rule. In this case the link permission is separated
into what is shown as the second rule: statement.
4. DFA: Expression Tree dump shows how these rules are combined together
You will notice that the rule conversion statement is fairly redundant currently as it just
show pcre to expression tree pcre. This will change when direct aare parsing occurs,
but currently serves to verify the pcre conversion step.
It is not the prettiest patch, as its touching some ugly code that is schedule to be cleaned
up/replaced. eg. convert_aaregex_to_pcre is going to replaced with native parse conversion
from an aare straight to the expression tree, and dfaflag passing will become part of the
rule set.
Instead of updating the profile name, allow a profile to have multiple
alternate names. Aliases are now added as alternate names and matched
through the xmatch dfa.
This will allow turning on and off various debug dumps as needed.
Multiple dump options can be specified as needed by using multiple
options.
eg. apparmor_parser -D variables
apparmor_parser -D dfa-tree -D dfa-simple-tree
The help option has also been updated to take an optional argument
to display help about give parameters, currently only dump is supported.
eg. apparmor_parser -h # standard help
apparmor_parser -h=dump # dump info about --dump options
Also Enable the dfa expression tree dumps
Change_profile was broken so that it couldn't parse expressions that
weren't path based or started with a variable. Furthermore if the name
held any expressions it was not hanlded correctly, as it was being passed
directly to dfa conversion without going through glob -> pcre conversion.
Change the globbing conversion to include [^\x00]. This reduces cases of
artifical overlap between globbing rules, and link rules. Link rules
are encoded to use a \0 char to seperate the 2 match parts of the rule.
Before this fix a glob * or ** could match against the \0 seperator
resulting the generation of dfa states for that overlap. This of course
can never happen as \0 is not a valid path name character.
In one example stress policy when adding the rule
owner /** rwl,
this change made the difference between having a dfa with 55152 states
and one with 30019
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
This causes the dfa engine to not strip trailing /
and to handle /*/ /**/ and /* and /** cases specially so that directories
don't get matched unintentionally
aare pcre
/foo/* -> /foo/[^/][^/]* so the dir /foo/ will not match the rule
/foo/** -> /foo/[^/].*
/*/foo -> /[^/][^/]*/foo so the rule won't match //foo
/**/foo -> /[^/].*/foo
rules that contain more than a * or ** between dir / elements do not
get converted, ie.
/foo*
/foo**
/foo*/
/foo**/
/*foo
/**foo
/*foo/
/**foo/
there is a known case where this patch is incomplete. When there
exists an alternation that can be empty and * or ** ie.
/{foo,}*
/{foo,*}
