Received: by 10.223.185.116 with SMTP id b49csp4513408wrg; Mon, 26 Feb 2018 20:19:24 -0800 (PST) X-Google-Smtp-Source: AH8x226nJ389Yvu1p22IOtbSIJU8kMTPtvTpt9KYjgobrQXUm3ve5rFDLpOJafNZIedzTuS+tM/c X-Received: by 2002:a17:902:14cb:: with SMTP id y11-v6mr13018473plg.294.1519705164402; Mon, 26 Feb 2018 20:19:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519705164; cv=none; d=google.com; s=arc-20160816; b=cCcwmAzqFwpmT/A9hShZe8nWuhhafpN9FzeqSJ7wRgVncHb+wrE/eF/52qm9e8bpon 1cxYCHyhgTZeY+2JpiDAYODPFOnbbpKzukOdIxTyvOMgc9muLSctt51Orqc1f6oPFHiX AVhYF6O+sVtmUCwuJqbLSFdi9qb/6+ju/5NpgUXK2l4Hd0FOMLcgX9Ndyod6BeoeEIQi UgXopL32b4s2iy/+xPggyGzYEQwGIuOtfxfwQ9nZlKw1bgX3xMLAY/avrcFp88dXbCar YywNIqMWUXV8BfzvL5SH4d1274RTWgNcNdBFz6AYI/ghL6fZW9InhM9BGceb4ugZqUf0 F+xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=G+CjZvxEHQqdTvkmacgFMmwRFyR1rlRUUbmvFQ/t1OI=; b=Bjur3Ptr1399nc/I/zDsnM1ISLyFEcZnQh/+BUxx2eOq7lQEIuqJW2So6DDY5DXx1F +Qu6on2FUv0ojaAs5Dxw9POwzgioqwpJnijyZfrmmrS/OkDrqliZ+2GdI6Ma/sGfQLQZ 4snDeYoYJyelYQXMq1y39LJqr+kXACOzmSWBuCVTj2yOsyUPbKoLFPvWxuRFZ8DmcyQy 2Ew/wRWKXqfg2Q4w7WZaC11bFk96PswQU1OcPR5jMJleV2NVuPz4CK8lJK8OUKWa0gEE 1d0ExPxGzt3g2Q7PgTLYF05MCmazmIYeaZk6W2Pa1K7WUQwQHO23WQU7S4NMzerOzAu0 uT5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Z33f4Rfu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j63si6457878pgc.484.2018.02.26.20.18.57; Mon, 26 Feb 2018 20:19:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Z33f4Rfu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbeB0ESG (ORCPT + 99 others); Mon, 26 Feb 2018 23:18:06 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:33634 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751759AbeB0ESD (ORCPT ); Mon, 26 Feb 2018 23:18:03 -0500 Received: by mail-io0-f195.google.com with SMTP id f1so5828831iob.0 for ; Mon, 26 Feb 2018 20:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G+CjZvxEHQqdTvkmacgFMmwRFyR1rlRUUbmvFQ/t1OI=; b=Z33f4RfuNl2Mlh2KjeRhB4I/FNPuoAGQg6+Sp1PmJbrwWOYNW1dOA+jtGT4FqhANgD erw4JxxAf1YFnnkxug1IwPilILBRgKEaOjyBhNH+Bn9tVX6qgZwFXpyfImCdZtwFB1PZ FCYKk73lQIpjjNLTLnSxaRpvNrrJ/yNHoEkA0/D0bB+XmJZBupCpMtSMsNk60dryfTJv a5l4i8Fjtph6QB3O8Y89o9Uj7mIjeoTirUxZj2YFFJEA3/jozx+KYLtaTLlotFLBSebl npH1+0xNlVnBg1YRz8Q6uSidSNJoIsFvq1TqHsQyeef3hdu1pOebEdawxLyIAd/XFC4M DHKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=G+CjZvxEHQqdTvkmacgFMmwRFyR1rlRUUbmvFQ/t1OI=; b=lnNLg7xAh869xi9QQVOdRrGXO6jsQ1v6odrK3AU+kzcpuVMQl3pzxLE/uFloNSUaxG owFvpjPqmgQTh9QcztD+R35GSsT5OOZ7u9pF48vFo11yfwsymZ0Dy7k0ylPP1rpm4QU2 RqeiRTy5BDbgVfXlwb2FAOkm2MMX17Yca3ncUjbkOfBjZY7NErwZcPF4DZsbRDNWZgvW xDddAHBsS9jIIPzI8T3R8yX3UEGxu0GJ7DGz4rAgw8hNesf/xtRD9hIrjKPENFfzwt98 x428a5DnODYHVHz0ZCIe+LdxNvTVXCwXhDu+yI9f2Ej6DXZSmZ2ZGk5elTrvP0e4i1E2 L8mA== X-Gm-Message-State: APf1xPDdVz1k+f/iyRzhTEanAh+T699pmFrm7xojSOpBL+aXwJfM9nr9 EDpyXpWvkXsGyPsYEM48qu6AyPqKNe7NSkEnRAkUVA== X-Received: by 10.107.151.209 with SMTP id z200mr8458027iod.150.1519705082522; Mon, 26 Feb 2018 20:18:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.137.101 with HTTP; Mon, 26 Feb 2018 20:17:42 -0800 (PST) In-Reply-To: <20180227004121.3633-9-mic@digikod.net> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-9-mic@digikod.net> From: Andy Lutomirski Date: Tue, 27 Feb 2018 04:17:42 +0000 Message-ID: Subject: Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: LKML , Alexei Starovoitov , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Tycho Andersen , Will Drewry , Kernel Hardening , Linux API , LSM List , Network Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 27, 2018 at 12:41 AM, Micka=C3=ABl Sala=C3=BCn wrote: > A landlocked process has less privileges than a non-landlocked process > and must then be subject to additional restrictions when manipulating > processes. To be allowed to use ptrace(2) and related syscalls on a > target process, a landlocked process must have a subset of the target > process' rules. > > Signed-off-by: Micka=C3=ABl Sala=C3=BCn > Cc: Alexei Starovoitov > Cc: Andy Lutomirski > Cc: Daniel Borkmann > Cc: David S. Miller > Cc: James Morris > Cc: Kees Cook > Cc: Serge E. Hallyn > --- > > Changes since v6: > * factor out ptrace check > * constify pointers > * cleanup headers > * use the new security_add_hooks() > --- > security/landlock/Makefile | 2 +- > security/landlock/hooks_ptrace.c | 124 +++++++++++++++++++++++++++++++++= ++++++ > security/landlock/hooks_ptrace.h | 11 ++++ > security/landlock/init.c | 2 + > 4 files changed, 138 insertions(+), 1 deletion(-) > create mode 100644 security/landlock/hooks_ptrace.c > create mode 100644 security/landlock/hooks_ptrace.h > > diff --git a/security/landlock/Makefile b/security/landlock/Makefile > index d0f532a93b4e..605504d852d3 100644 > --- a/security/landlock/Makefile > +++ b/security/landlock/Makefile > @@ -3,4 +3,4 @@ obj-$(CONFIG_SECURITY_LANDLOCK) :=3D landlock.o > landlock-y :=3D init.o chain.o task.o \ > tag.o tag_fs.o \ > enforce.o enforce_seccomp.o \ > - hooks.o hooks_cred.o hooks_fs.o > + hooks.o hooks_cred.o hooks_fs.o hooks_ptrace.o > diff --git a/security/landlock/hooks_ptrace.c b/security/landlock/hooks_p= trace.c > new file mode 100644 > index 000000000000..f1b977b9c808 > --- /dev/null > +++ b/security/landlock/hooks_ptrace.c > @@ -0,0 +1,124 @@ > +/* > + * Landlock LSM - ptrace hooks > + * > + * Copyright =C2=A9 2017 Micka=C3=ABl Sala=C3=BCn > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2, as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include /* ARRAY_SIZE */ > +#include > +#include /* struct task_struct */ > +#include > + > +#include "common.h" /* struct landlock_prog_set */ > +#include "hooks.h" /* landlocked() */ > +#include "hooks_ptrace.h" > + > +static bool progs_are_subset(const struct landlock_prog_set *parent, > + const struct landlock_prog_set *child) > +{ > + size_t i; > + > + if (!parent || !child) > + return false; > + if (parent =3D=3D child) > + return true; > + > + for (i =3D 0; i < ARRAY_SIZE(child->programs); i++) { ARRAY_SIZE(child->programs) seems misleading. Is there no define NUM_LANDLOCK_PROG_TYPES or similar? > + struct landlock_prog_list *walker; > + bool found_parent =3D false; > + > + if (!parent->programs[i]) > + continue; > + for (walker =3D child->programs[i]; walker; > + walker =3D walker->prev) { > + if (walker =3D=3D parent->programs[i]) { > + found_parent =3D true; > + break; > + } > + } > + if (!found_parent) > + return false; > + } > + return true; > +} If you used seccomp, you'd get this type of check for free, and it would be a lot easier to comprehend. AFAICT the only extra leniency you're granting is that you're agnostic to the order in which the rules associated with different program types were applied, which could easily be added to seccomp.