- 16 1月, 2017 20 次提交
-
-
由 John Johansen 提交于
Store loaded policy and allow introspecting it through apparmorfs. This has several uses from debugging, policy validation, and policy checkpoint and restore for containers. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Policy management will be expanded beyond traditional unconfined root. This will require knowning the profile of the task doing the management and the ns view. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Prepare for a tighter pairing of user namespaces and apparmor policy namespaces, by making the ns to be viewed available. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Prepare for a tighter pairing of user namespaces and apparmor policy namespaces, by making the ns to be viewed available and checking that the user namespace level is the same as the policy ns level. This strict pairing will be relaxed once true support of user namespaces lands. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
This is prep work for fs operations being able to remove namespaces. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Instead of testing whether a given dfa exists in every code path, have a default null dfa that is used when loaded policy doesn't provide a dfa. This will let us get rid of special casing and avoid dereference bugs when special casing is missed. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
When possible its better to name a learning profile after the missing profile in question. This allows for both more informative names and for profile reuse. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
prepare_ns() will need to be called from alternate views, and namespaces will need to be created via different interfaces. So refactor and allow specifying the view ns. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Rename to the shorter and more familiar shell cmd name Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Proxy is shorter and a better fit than replaceby, so rename it. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Invalid does not convey the meaning of the flag anymore so rename it. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Policy namespaces will be diverging from profile management and expanding so put it in its own file. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
- 12 7月, 2016 7 次提交
-
-
由 John Johansen 提交于
the policy_lock parameter is a one way switch that prevents policy from being further modified. Unfortunately some of the module parameters can effectively modify policy by turning off enforcement. split policy_admin_capable into a view check and a full admin check, and update the admin check to test the policy_lock parameter. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
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: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
Currently logging of a successful profile load only logs the basename of the profile. This can result in confusion when a child profile has the same name as the another profile in the set. Logging the hname will ensure there is no confusion. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
currently only the profile that is causing the failure is logged. This makes it more confusing than necessary about which profiles loaded and which didn't. So make sure to log success and failure messages for all profiles in the set being loaded. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
When set atomic replacement is used and the parent is updated before the child, and the child did not exist in the old parent so there is no direct replacement then the new child is incorrectly added to the old parent. This results in the new parent not having the child(ren) that it should and the old parent when being destroyed asserting the following error. AppArmor: policy_destroy: internal error, policy '<profile/name>' still contains profiles Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
- 16 10月, 2013 1 次提交
-
-
由 John Johansen 提交于
BugLink: http://bugs.launchpad.net/bugs/1235523 This fixes the following kmemleak trace: unreferenced object 0xffff8801e8c35680 (size 32): comm "apparmor_parser", pid 691, jiffies 4294895667 (age 13230.876s) hex dump (first 32 bytes): e0 d3 4e b5 ac 6d f4 ed 3f cb ee 48 1c fd 40 cf ..N..m..?..H..@. 5b cc e9 93 00 00 00 00 00 00 00 00 00 00 00 00 [............... backtrace: [<ffffffff817a97ee>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811ca9f3>] __kmalloc+0x103/0x290 [<ffffffff8138acbc>] aa_calc_profile_hash+0x6c/0x150 [<ffffffff8138074d>] aa_unpack+0x39d/0xd50 [<ffffffff8137eced>] aa_replace_profiles+0x3d/0xd80 [<ffffffff81376937>] profile_replace+0x37/0x50 [<ffffffff811e9f2d>] vfs_write+0xbd/0x1e0 [<ffffffff811ea96c>] SyS_write+0x4c/0xa0 [<ffffffff817ccb1d>] system_call_fastpath+0x1a/0x1f [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 30 9月, 2013 1 次提交
-
-
由 John Johansen 提交于
The recent 3.12 pull request for apparmor was missing a couple rcu _protected access modifiers. Resulting in the follow suspicious RCU usage [ 29.804534] [ INFO: suspicious RCU usage. ] [ 29.804539] 3.11.0+ #5 Not tainted [ 29.804541] ------------------------------- [ 29.804545] security/apparmor/include/policy.h:363 suspicious rcu_dereference_check() usage! [ 29.804548] [ 29.804548] other info that might help us debug this: [ 29.804548] [ 29.804553] [ 29.804553] rcu_scheduler_active = 1, debug_locks = 1 [ 29.804558] 2 locks held by apparmor_parser/1268: [ 29.804560] #0: (sb_writers#9){.+.+.+}, at: [<ffffffff81120a4c>] file_start_write+0x27/0x29 [ 29.804576] #1: (&ns->lock){+.+.+.}, at: [<ffffffff811f5d88>] aa_replace_profiles+0x166/0x57c [ 29.804589] [ 29.804589] stack backtrace: [ 29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5 [ 29.804599] Hardware name: ASUSTeK Computer Inc. UL50VT /UL50VT , BIOS 217 03/01/2010 [ 29.804602] 0000000000000000 ffff8800b95a1d90 ffffffff8144eb9b ffff8800b94db540 [ 29.804611] ffff8800b95a1dc0 ffffffff81087439 ffff880138cc3a18 ffff880138cc3a18 [ 29.804619] ffff8800b9464a90 ffff880138cc3a38 ffff8800b95a1df0 ffffffff811f5084 [ 29.804628] Call Trace: [ 29.804636] [<ffffffff8144eb9b>] dump_stack+0x4e/0x82 [ 29.804642] [<ffffffff81087439>] lockdep_rcu_suspicious+0xfc/0x105 [ 29.804649] [<ffffffff811f5084>] __aa_update_replacedby+0x53/0x7f [ 29.804655] [<ffffffff811f5408>] __replace_profile+0x11f/0x1ed [ 29.804661] [<ffffffff811f6032>] aa_replace_profiles+0x410/0x57c [ 29.804668] [<ffffffff811f16d4>] profile_replace+0x35/0x4c [ 29.804674] [<ffffffff81120fa3>] vfs_write+0xad/0x113 [ 29.804680] [<ffffffff81121609>] SyS_write+0x44/0x7a [ 29.804687] [<ffffffff8145bfd2>] system_call_fastpath+0x16/0x1b [ 29.804691] [ 29.804694] =============================== [ 29.804697] [ INFO: suspicious RCU usage. ] [ 29.804700] 3.11.0+ #5 Not tainted [ 29.804703] ------------------------------- [ 29.804706] security/apparmor/policy.c:566 suspicious rcu_dereference_check() usage! [ 29.804709] [ 29.804709] other info that might help us debug this: [ 29.804709] [ 29.804714] [ 29.804714] rcu_scheduler_active = 1, debug_locks = 1 [ 29.804718] 2 locks held by apparmor_parser/1268: [ 29.804721] #0: (sb_writers#9){.+.+.+}, at: [<ffffffff81120a4c>] file_start_write+0x27/0x29 [ 29.804733] #1: (&ns->lock){+.+.+.}, at: [<ffffffff811f5d88>] aa_replace_profiles+0x166/0x57c [ 29.804744] [ 29.804744] stack backtrace: [ 29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5 [ 29.804753] Hardware name: ASUSTeK Computer Inc. UL50VT /UL50VT , BIOS 217 03/01/2010 [ 29.804756] 0000000000000000 ffff8800b95a1d80 ffffffff8144eb9b ffff8800b94db540 [ 29.804764] ffff8800b95a1db0 ffffffff81087439 ffff8800b95b02b0 0000000000000000 [ 29.804772] ffff8800b9efba08 ffff880138cc3a38 ffff8800b95a1dd0 ffffffff811f4f94 [ 29.804779] Call Trace: [ 29.804786] [<ffffffff8144eb9b>] dump_stack+0x4e/0x82 [ 29.804791] [<ffffffff81087439>] lockdep_rcu_suspicious+0xfc/0x105 [ 29.804798] [<ffffffff811f4f94>] aa_free_replacedby_kref+0x4d/0x62 [ 29.804804] [<ffffffff811f4f47>] ? aa_put_namespace+0x17/0x17 [ 29.804810] [<ffffffff811f4f0b>] kref_put+0x36/0x40 [ 29.804816] [<ffffffff811f5423>] __replace_profile+0x13a/0x1ed [ 29.804822] [<ffffffff811f6032>] aa_replace_profiles+0x410/0x57c [ 29.804829] [<ffffffff811f16d4>] profile_replace+0x35/0x4c [ 29.804835] [<ffffffff81120fa3>] vfs_write+0xad/0x113 [ 29.804840] [<ffffffff81121609>] SyS_write+0x44/0x7a [ 29.804847] [<ffffffff8145bfd2>] system_call_fastpath+0x16/0x1b Reported-by: miles.lane@gmail.com CC: paulmck@linux.vnet.ibm.com Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 15 8月, 2013 8 次提交
-
-
由 John Johansen 提交于
Add basic interface files to access namespace and profile information. The interface files are created when a profile is loaded and removed when the profile or namespace is removed. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Allow emulating the default profile behavior from boot, by allowing loading of a profile in the unconfined state into a new NS. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
namespaces now completely use the unconfined profile to track the refcount and rcu freeing cycle. So rework the code to simplify (track everything through the profile path right up to the end), and move the rcu_head from policy base to profile as the namespace no longer needs it. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
ns->unconfined is being used read side without locking, nor rcu but is being updated when a namespace is removed. This works for the root ns which is never removed but has a race window and can cause failures when children namespaces are removed. Also ns and ns->unconfined have a circular refcounting dependency that is problematic and must be broken. Currently this is done incorrectly when the namespace is destroyed. Fix this by forward referencing unconfined via the replacedby infrastructure instead of directly updating the ns->unconfined pointer. Remove the circular refcount dependency by making the ns and its unconfined profile share the same refcount. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NSeth Arnold <seth.arnold@canonical.com>
-
由 John Johansen 提交于
remove the use of replaced by chaining and move to profile invalidation and lookup to handle task replacement. Replacement chaining can result in large chains of profiles being pinned in memory when one profile in the chain is use. With implicit labeling this will be even more of a problem, so move to a direct lookup method. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
previously profiles had to be loaded one at a time, which could result in cases where a replacement of a set would partially succeed, and then fail resulting in inconsistent policy. Allow multiple profiles to replaced "atomically" so that the replacement either succeeds or fails for the entire set of profiles. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
- 28 4月, 2013 3 次提交
-
-
由 John Johansen 提交于
smatch reports error: potential NULL dereference 'ns'. this can not actually occur because it relies on aa_split_fqname setting both ns_name and name as null but ns_name will actually always have a value in this case. so remove the unnecessary if (ns_name) conditional that is resulting in the false positive further down. Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Move the free_profile fn ahead of aa_alloc_profile so it can be used in aa_alloc_profile without a forward declaration. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NKees Cook <kees@ubuntu.com>
-
由 John Johansen 提交于
The sid is not going to be a direct property of a profile anymore, instead it will be directly related to the label, and the profile will pickup a label back reference. For null-profiles replace the use of sid with a per namespace unique id. Signed-off-by: NJohn Johansen <john.johansen@canonical.com> Acked-by: NKees Cook <kees@ubuntu.com>
-