| Message ID | 1332846967-30282-1-git-send-email-john.johansen@canonical.com |
|---|---|
| State | New |
| Headers | show |
Lemme know if this appears in Linus' repo before Tuesday. Is this a candidate for 3.0/3.2 stable ?
On 03/27/2012 05:03 AM, Tim Gardner wrote: > Lemme know if this appears in Linus' repo before Tuesday. Is this a > candidate for 3.0/3.2 stable ? > It could be applied to those but it hasn't been properly supported by the userspace before Precise so I didn't see the point.
On 03/27/2012 05:03 AM, Tim Gardner wrote:
> Lemme know if this appears in Linus' repo before Tuesday. Is this a
This is upstream as commit
0421ea91ddc7895a5a68d3bc670ed4b8e6448a42
diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c index 51cd053..afa8671 100644 --- a/security/apparmor/domain.c +++ b/security/apparmor/domain.c @@ -415,7 +415,8 @@ int apparmor_bprm_set_creds(struct linux_binprm *bprm) * exec\0change_profile */ state = aa_dfa_null_transition(profile->file.dfa, state); - cp = change_profile_perms(profile, cxt->onexec->ns, name, + cp = change_profile_perms(profile, cxt->onexec->ns, + cxt->onexec->base.name, AA_MAY_ONEXEC, state); if (!(cp.allow & AA_MAY_ONEXEC)) diff --git a/security/apparmor/file.c b/security/apparmor/file.c index 3022c0f..5d176f2 100644 --- a/security/apparmor/file.c +++ b/security/apparmor/file.c @@ -215,6 +215,8 @@ static struct file_perms compute_perms(struct aa_dfa *dfa, unsigned int state, /* change_profile wasn't determined by ownership in old mapping */ if (ACCEPT_TABLE(dfa)[state] & 0x80000000) perms.allow |= AA_MAY_CHANGE_PROFILE; + if (ACCEPT_TABLE(dfa)[state] & 0x40000000) + perms.allow |= AA_MAY_ONEXEC; return perms; }
Patch submitted upstream, but not merged yet. Fix failure in aa_change_onexec api when the request is made from a confined task. This failure was caused by two problems The AA_MAY_ONEXEC perm was not being mapped correctly for this case. The executable name was being checked as second time instead of using the requested onexec profile name, which may not be the same as the exec profile name. This mistake can not be exploited to grant extra permission because of the above flaw where the ONEXEC permission was not being mapped so it will not be granted. BugLink: http://bugs.launchpad.net/bugs/963756 Signed-off-by: John Johansen <john.johansen@canonical.com> --- security/apparmor/domain.c | 3 ++- security/apparmor/file.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletions(-)