- 06 Apr, 2016 40 commits
-
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
John Johansen authored
label_merge_insert - requires that a replacedby exists on either the existing in tree label or on the label attempting to be added. If we get into a situation where the in tree label is replacedby and the replacedby doesn't exists an oops will occur. Unfortunately we can not know if the intree label was created with or without a replacedby so, we always have to create the replacedby. Instead Make sure this is so be tying to the label_allocation. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
The old label needs to be removed, so call label_remove on it. This is only needed by the inv path but that path shares code and removing won't hurt the non-inv path. Also the proxy redirect needs to be done at the insert or after to make sure the redirect target is correct. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
This also adds auditing of the targets name for Denials due to ptrace restrictions. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
When finding a child profile via an rcu critical section, the profile may be put and scheduled for deletion after the child is found but before its refcount is incremented. Protect against this by repeating the lookup if the profiles refcount is 0 and is one its way to deletion. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
aa_label_remove needs to take the ls write lock but, we are already holding it so move to __aa_label_remove also fix bug where the old label is not being forwarded to the new label when it results in a new namespace due to an the old ns being removed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1482943 apparmor use kern_path() to lookup the path of the dev_name, and when this fails apparmor emits a DENIED log message. However for bind and move mounts the underlying code does a call to kern_path() regardless of apparmor being present and so has the same failure. In these cases when kern_path() fails apparmor is not responsible for the mount failure as the kernel will fail the mount regarless of apparmor's presence, so just return the error and don't log an apparmor audit message. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
fixup of [20/23] apparmor: Fix: refcount bug when inserting label update that transitions ns may want to split into 2 patches Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
File permissions have not been updated to use the newer compute_perms fn yet. So export the fn to compute the file permissions and use it in query_label until file permissions have been converted. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Double calling remove on a label does a double update of the replacedby which is extra work and messes up tracking stats. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
There are a few cases when racing an update where a label can be allocated with its replacedby, and end up being freed directly because it lost the race and will not be used. However without breaking the circular ref between the label and its replacedby, a double free of the label will occur: label being freed ref count from label to replacedby is put, ref count from replacedby is put label is scheduled to be freed replacedby is freed label is freed rcu call back to free label triggers label is freed again Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
We already have a refcount on l, and aa_label_insert() returns another refcount so we need to make sure to put the extra one. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
UBUNTU: SAUCE: apparmor: Fix: now that insert can force replacement use it instead of remove_and_insert Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
pivotroot medition may change the tasks current cred if the a transition rule is defined. However aa_begin_current_label(), and aa_end_current_label() define a critical section block where the tasks cred label are not allowed to be updated. Specifically they do not take a refcount on the tasks cred, but will return a refcounted label IF there is an updated version of the label that can not be immediately updated. The aa_end_current_label() fn detects whether the label used has a refcount to put by comparing the label to the task's cred label, and if its different putting label. When the task cred's label is changed within this critical section, the cred update will put the creds label reference, and then the aa_begin_current_label() fn will detect the difference in the cred and working label and subsequentially do an extra put on the label. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
don't put the reference when sharing a replacedby until after all over references are gotten, otherwise the label might drop to a 0 refcount and start being freed, even though it should be held by the shared replacedby. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 The allocation of a replacedby in the label merge path needs to be done using GFP_ATOMIC. specifically aa_label_merge() is called from a context in file.c that passes GFP_ATOMIC to aa_label_merge() which then is doing GFP_KERNEL for the replacedby allocation. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 replacedby updates must be able to occur when in an rcu critical sections, and when spin locks are held. As such it can not use a mutex lock to protect its critical section. Since replacedby updates are accompanied by labelset insertion and removals use the labelset write lock to protect the update critical section. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 __aa_update_replacedby needs the ns lock held, this is done for profile load/replace/remove case and the label_update case but not when called from the label merge paths. NOTE: this is just a conceptal "fix", it can not be validly used as label_merge is called from atomic context and taking a mutex_lock may sleep. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 When aa_put_label() is called from a fn that is holding the labelset lock, it can result in a deadlock if the put count reaches 0 triggering the kref callback, which tries to take the label set lock. Rework so the label_kref callback deferrs removing the label from the labelset until the rcu callback, ensuring the lock is not held by the calling code. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 label_vec_merge should only do the insertion after the vector is copied. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 Basic profile labels always have a replacedby allocated and set but the code used to create labels from merges without a replacedby and let label_update allocate and set those labels replacedby structs. While the label_merge fix addressed the race between label_merge and label_update, it still left a bug where labels from merges race label_update so that they remain permanently stale, because they don't have proper replacedby information that should be updated during their replacement. Specifically a label from a merge will not have a replacedby if it has never been through a label_update cycle, and the direct replacement from the label_merge fix is NOT updating the replacedby to avoid doing allocations under lock. This results in the old label being permanently diconnected and its references never updating correctly. To fix this create all labels that result from a merge with a replacedby. This results in all labels inserted into the labelset having valid replacedby structs. In the case that the insertion of a label results in a replacement due to it creating an updated version of the label, the old labels replacedby will be reused and the new one can be freed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
if aa_label_alloc() fails the refs taken on a and b are leaked. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 The labelset does not hold a refcount on the labels its contains, all lookups are done under lock. However in the window between finding a label in the labelset and getting its reference, where the last label reference can be put causing the label to begin its cleanup. Ensure the any label in the set has valid reference before returning its reference. We do this by getting its reference and failing on that reference if the label has begun cleanup. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 Fix a couple of bugs in label merge. - the unconfined status may not be correctly set in the case of a stale profile - if merge(A,B) == A' where A' is revised none stale version of A then the insertion of A' to replace A can fail. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
And label and replacedby reference poisoning to make catching and debugging label refcount errors easier. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
UBUNTU: SAUCE: apparmor: Fix: ensure aa_get_newest will trip debugging if the replacedby is not setup BugLink: http://bugs.launchpad.net/bugs/1448912 While we are at it, also catch any potential refcounting errors arround the replacedby label dereference. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 it is possible for a label_merge to be racing label_update resulting in the AA_BUG(__aa_label_remove_and_insert()) to trip. Instead check if a version of label has already been inserted and gracefully fail if label_update lost the race. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1430546 The profile update mechanism can return a stale label when an update to the task's cred fails. Fix this so that the current label is always returned. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1430546Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Passing NULL ns to label print fns is used as shorthand in the a few places to mean default to the current ns (ie. aa_current_ns()). However not all the print routines support this. Instead of fixing the call sites that pass null into the label_print fns, update all the label_print fns to support this use. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-