mirror of
https://gitlab.com/apparmor/apparmor
synced 2025-08-30 22:05:27 +00:00
Add Audit control to AppArmor through, the use of audit and deny
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 commit is contained in:
@@ -503,8 +503,21 @@ static int process_dfa_entry(aare_ruleset_t *dfarules, struct cod_entry *entry)
|
||||
AA_EXEC_INHERIT)
|
||||
entry->mode |= AA_EXEC_MMAP << AA_USER_SHIFT;
|
||||
|
||||
if (!aare_add_rule(dfarules, tbuf, entry->mode))
|
||||
return FALSE;
|
||||
/* the link bit on the first pair entry should not get masked
|
||||
* out by a deny rule, as both pieces of the link pair must
|
||||
* match. audit info for the link is carried on the second
|
||||
* entry of the pair
|
||||
*/
|
||||
if (entry->deny && (entry->mode & AA_LINK_BITS)) {
|
||||
if (!aare_add_rule(dfarules, tbuf, entry->deny,
|
||||
entry->mode & ~AA_LINK_BITS,
|
||||
entry->audit & ~AA_LINK_BITS))
|
||||
return FALSE;
|
||||
} else {
|
||||
if (!aare_add_rule(dfarules, tbuf, entry->deny, entry->mode,
|
||||
entry->audit))
|
||||
return FALSE;
|
||||
}
|
||||
if (entry->mode & (AA_LINK_BITS)) {
|
||||
/* add the pair rule */
|
||||
char lbuf[PATH_MAX + 8];
|
||||
@@ -522,7 +535,7 @@ static int process_dfa_entry(aare_ruleset_t *dfarules, struct cod_entry *entry)
|
||||
perms |= LINK_TO_LINK_SUBSET(perms);
|
||||
vec[1] = "/[^/].*";
|
||||
}
|
||||
if (!aare_add_rule_vec(dfarules, perms, 2, vec))
|
||||
if (!aare_add_rule_vec(dfarules, entry->deny, perms, entry->audit & AA_LINK_BITS, 2, vec))
|
||||
return FALSE;
|
||||
}
|
||||
if (entry->mode & AA_CHANGE_PROFILE) {
|
||||
@@ -530,10 +543,10 @@ static int process_dfa_entry(aare_ruleset_t *dfarules, struct cod_entry *entry)
|
||||
char *vec[2];
|
||||
vec[0] = entry->namespace;
|
||||
vec[1] = entry->name;
|
||||
if (!aare_add_rule_vec(dfarules, AA_CHANGE_PROFILE, 2, vec))
|
||||
if (!aare_add_rule_vec(dfarules, 0, AA_CHANGE_PROFILE, 0, 2, vec))
|
||||
return FALSE;
|
||||
} else {
|
||||
if (!aare_add_rule(dfarules, entry->name, AA_CHANGE_PROFILE))
|
||||
if (!aare_add_rule(dfarules, entry->name, 0, AA_CHANGE_PROFILE, 0))
|
||||
return FALSE;
|
||||
}
|
||||
}
|
||||
|
Reference in New Issue
Block a user