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>
parsing, and precompilation of policy. This allows finding the most
recent text time stamp during parsing and this is then compared to
the cache file time stamp.
While this is slightly slower than the cache file check that only
validated against the profile file it fixes the bug where abstraction
updates do not cause the cache file to become invalid.
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.
Alias was broken because it when an alias was made the old path was completely
removed and there was no way to specify it. Update it so aliases just add
an new duplicate rule instead.
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
thing again. Fix to use the kernel's definition of AF_MAX in
linux/socket.h if it's larger than glibc's AF_MAX definition in
sys/socket.h and add a wrapper function so that we don't have include
af_names.h everywhere.
Also, fix memory leaks around the handling of network entries of
policies.
- fix "Namespcae" tyop
- get rid of sub_name and default_deny from the main profile struct as
they haven't been used for a long time; also eliminates their output
from the debugging output.
- emit dumped parsing structure with only one -d, users were confuzzled
and it was not documented that you needed to use -dd to get it to
output anything if DEBUG wasn't set when compiling.
removing profiles, as the list is unstable after additions or removals.
- Add the ability to loaded precompiled policy by specifying the -B
option, which can be combined with --add or --replace
- rc.apparmor.functions were not correctly removing profiles on replace and
reload, also convert to using the module interface directly bypassing the
parser.
- fix cx -> named transitions
- fix apparmor_parser -N so that it emits hats as profiles under new kernel
modules. This is the correct behavior as hats are promoted to profiles.
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,
}
