Message ID | 20210716161438.894779-1-georgia.garcia@canonical.com |
---|---|
Headers | show |
Series | Fix ptrace read check (LP: 1890848) | expand |
On Fri, Jul 16, 2021 at 1:15 PM Georgia Garcia <georgia.garcia@canonical.com> wrote: > > BugLink: https://bugs.launchpad.net/bugs/1890848 > > SRU Justification: > > [Impact] > Permission 'ptrace trace' is required to readlink() /proc/*/ns/*, when > only 'ptrace read' should be required according to 'man namespaces': > > "Permission to dereference or read (readlink(2)) these symbolic links > is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see > ptrace(2)." > > [Fix] > > Upstream commit 338d0be437ef10e247a35aed83dbab182cf406a2 fixes ptrace > read check. > > [Test Plan] > > BugLink contains the source of a binary that reproduces the issue. In > summary, it executes readlink() on /proc/*/ns/*. There's also a policy > that has only 'ptrace read' permission. When the bug is fixed, > execution is allowed. > > [Where problems could occur] > > The regression can be considered as low, since it's lowering the number > of permissions required. Existing policies that already contain the > permission 'ptrace trace' and 'ptrace read' will have a broader policy > than required. > > John Johansen (1): > apparmor: fix ptrace read check > > security/apparmor/lsm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Thank you Georgia, makes sense to me! Acked-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com> On 7/16/21 10:14 AM, Georgia Garcia wrote: > BugLink: https://bugs.launchpad.net/bugs/1890848 > > SRU Justification: > > [Impact] > Permission 'ptrace trace' is required to readlink() /proc/*/ns/*, when > only 'ptrace read' should be required according to 'man namespaces': > > "Permission to dereference or read (readlink(2)) these symbolic links > is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see > ptrace(2)." > > [Fix] > > Upstream commit 338d0be437ef10e247a35aed83dbab182cf406a2 fixes ptrace > read check. > > [Test Plan] > > BugLink contains the source of a binary that reproduces the issue. In > summary, it executes readlink() on /proc/*/ns/*. There's also a policy > that has only 'ptrace read' permission. When the bug is fixed, > execution is allowed. > > [Where problems could occur] > > The regression can be considered as low, since it's lowering the number > of permissions required. Existing policies that already contain the > permission 'ptrace trace' and 'ptrace read' will have a broader policy > than required. > > John Johansen (1): > apparmor: fix ptrace read check > > security/apparmor/lsm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >
Applied to bionic master-next. Thank you! -Kelsey On 2021-07-16 13:14:37 , Georgia Garcia wrote: > BugLink: https://bugs.launchpad.net/bugs/1890848 > > SRU Justification: > > [Impact] > Permission 'ptrace trace' is required to readlink() /proc/*/ns/*, when > only 'ptrace read' should be required according to 'man namespaces': > > "Permission to dereference or read (readlink(2)) these symbolic links > is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see > ptrace(2)." > > [Fix] > > Upstream commit 338d0be437ef10e247a35aed83dbab182cf406a2 fixes ptrace > read check. > > [Test Plan] > > BugLink contains the source of a binary that reproduces the issue. In > summary, it executes readlink() on /proc/*/ns/*. There's also a policy > that has only 'ptrace read' permission. When the bug is fixed, > execution is allowed. > > [Where problems could occur] > > The regression can be considered as low, since it's lowering the number > of permissions required. Existing policies that already contain the > permission 'ptrace trace' and 'ptrace read' will have a broader policy > than required. > > John Johansen (1): > apparmor: fix ptrace read check > > security/apparmor/lsm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team