AppArmor's use of RCU is non-standard in that the profile is RCU protected
and ref count protected at the same time. A race can occur between
removing a task removing profile reference from the subdomain and another
task getting a reference to the profile from the subdomain.
Task A Task B
tmp = read subdomain->profile
subdomain->profile = NULL
aa_put_profile(subdomain->profile) <- ref_count goes to 0
aa_get_profile(tmp)
profile is put on rcu_callback list
aa_put_profile(profile)
profile is put on rcu_callback list
again using same rcu_head
The problem lies in the subtle distinction of the profile reference count
held by a subdomain, vs. all other profile reference counts.
The reference count held by the subdomain is an RCU protected reference
count so the profile it references can only be freed after an rcu cycle.
The reference being only read side RCU protected can be read at any
point is the rcu cycle before the subdomain->profile reference is updated.
The updating of the profile reference count is not atomic to this
resulting in the race.
Using seperate put functions for the rcu protected subdomain->profile
reference vs other profile references, where the rcu put adds the profile
to the rcu callback list and the regular put frees the profile directly
won't work either since rcu reference count has the same race.
This just results in the profile being freed twice instead of putting the
profile on the rcu callback list twice.
however in that the capability hooks never get called. This shouldn't
be a big problem since AppArmor already composes capability through
use of common cap.
This just prevents the user from having to deal with/understand the
error message that occurs when the capability module fails to stack
with AppArmor.
than the VALID_FS_CHECK because it is simpler and can account for
all filesystem types that shouldn't be mediated. Where the old
VALID_FS_CHECK would fail for filesystem not in its list.
result in incorrect removal of " (deleted)" from the pathname.
The race is as follows:
the path contains " (deleted)", which is unlikely but valid
during path lookup the path is valid
after path lookup before the deleted test the dentry is unhashed
the deleted test now succeeds but the pathname never had " (deleted)"
appended by d_path. The paths " (deleted)" string is removed
and an incorrect path is returned
are currently running while logprof/genprof is used being left in the
null-complain profile instead of being moved to the profile the user
has just specified.
the profiles are updated correctly though, so if the application is
stopped and restarted, it will be confined by the appropriate profile.
utils package and manually fixed some places where perltidy's
reformatting made it harder to read. the options used were--
-i=4 # 4-space indentation
-l=0 # unlimited line length (for now)
-pt=2 # slightly tightened parens
-ce # cuddled elses
-nolq # don't outdent long quotes
-nsfs # don't add spaces in front of semi-colons in for ( ) statements
-isbc # only indent block comments that have whitespace in front of them
-otr # don't place a break between a comma and an opening brace
the code will be refactored to make it possible to switch to using
80-column line-breaks without resorting to really nasty formatting
constructs.
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,*}
