linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: "Mickaël Salaün" <mic@digikod.net>,
	LKML <linux-kernel@vger.kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Casey Schaufler" <casey@schaufler-ca.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"David Drysdale" <drysdale@google.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	"James Morris" <james.l.morris@oracle.com>,
	"Jann Horn" <jann@thejh.net>, "Jonathan Corbet" <corbet@lwn.net>,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Paul Moore" <paul@paul-moore.com>,
	"Sargun Dhillon" <sargun@sargun.me>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	"Shuah Khan" <shuah@kernel.org>, "Tejun Heo" <tj@kernel.org>,
	"Thomas Graf" <tgraf@suug.ch>, "Tycho Andersen" <tycho@tycho.ws>,
	"Will Drewry" <wad@chromium.org>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
	"Linux API" <linux-api@vger.kernel.org>,
	"LSM List" <linux-security-module@vger.kernel.org>,
	"Network Development" <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions
Date: Tue, 27 Feb 2018 23:23:36 +0000	[thread overview]
Message-ID: <CALCETrV_BVc44YYq6g8PCpeUYuqQaooVoQSQ7Y=VpuaBshQgQg@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUTiUeV71jgYWup0CZwG8eQ3=W7X5FgJqmgPxnYbFsccw@mail.gmail.com>

On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 27/02/2018 06:01, Andy Lutomirski wrote:
>>>
>>>
>>>> On Feb 26, 2018, at 8:17 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>
>>>>> On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün <mic@digikod.net> 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ël Salaün <mic@digikod.net>
>>>>> Cc: Alexei Starovoitov <ast@kernel.org>
>>>>> Cc: Andy Lutomirski <luto@amacapital.net>
>>>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>>>> Cc: David S. Miller <davem@davemloft.net>
>>>>> Cc: James Morris <james.l.morris@oracle.com>
>>>>> Cc: Kees Cook <keescook@chromium.org>
>>>>> Cc: Serge E. Hallyn <serge@hallyn.com>
>>>>> ---
>>>>>
>>>>> 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) := landlock.o
>>>>> landlock-y := 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_ptrace.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 © 2017 Mickaël Salaün <mic@digikod.net>
>>>>> + *
>>>>> + * 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 <asm/current.h>
>>>>> +#include <linux/errno.h>
>>>>> +#include <linux/kernel.h> /* ARRAY_SIZE */
>>>>> +#include <linux/lsm_hooks.h>
>>>>> +#include <linux/sched.h> /* struct task_struct */
>>>>> +#include <linux/seccomp.h>
>>>>> +
>>>>> +#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 == child)
>>>>> +               return true;
>>>>> +
>>>>> +       for (i = 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 = false;
>>>>> +
>>>>> +               if (!parent->programs[i])
>>>>> +                       continue;
>>>>> +               for (walker = child->programs[i]; walker;
>>>>> +                               walker = walker->prev) {
>>>>> +                       if (walker == parent->programs[i]) {
>>>>> +                               found_parent = 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.
>>>
>>> On second thought, this is all way too complicated.  I think the correct logic is either "if you are filtered by Landlock, you cannot ptrace anything" or to delete this patch entirely.
>>
>> This does not fit a lot of use cases like running a container
>> constrained with some Landlock programs. We should not deny users the
>> ability to debug their stuff.
>>
>> This patch add the minimal protection which are needed to have
>> meaningful Landlock security policy. Without it, they may be easily
>> bypassable, hence useless.
>>
>
> I think you're wrong here.  Any sane container trying to use Landlock
> like this would also create a PID namespace.  Problem solved.  I still
> think you should drop this patch.
>
>>
>>> If something like Tycho's notifiers goes in, then it's not obvious that, just because you have the same set of filters, you have the same privilege.  Similarly, if a feature that lets a filter query its cgroup goes in (and you proposed this once!) then the logic you implemented here is wrong.
>>
>> I don't get your point. Please take a look at the tests (patch 10).
>
> I don't know what you want me to look at.
>
> What I'm saying is: suppose I write a filter like this:
>
> bool allow_some_action(void)
> {
>   int value_from_container_manager = call_out_to_user_notifier();
>   return value_from_container_manager == 42;
> }
>
> or
>
> bool allow_some_action(void)
> {
>   return my_cgroup_is("/foo/bar");
> }
>
> In both of these cases, your code will do the wrong thing.
>
>>
>>>
>>> Or you could just say that it's the responsibility of a Landlock user to properly filter ptrace() just like it's the responsibility of seccomp users to filter ptrace if needed.
>>
>> A user should be able to enforce a security policy on ptrace as well,
>> but this patch enforce a minimal set of security boundaries. It will be
>> easy to add a new Landlock program type to get this kind of access control.
>
> It sounds like you want Landlock to be a complete container system all
> by itself.  I disagree with that design goal.

Having actually read your series more correctly now (oops!), I still
think that this patch should be dropped.  I can see an argument for
having a flag that one can set when adding a seccomp filter that says
"prevent ptrace of any child that doesn't have this exact stack
installed", but I think that could be added later and should not be
part of an initial submission.  For now, Landlock users can block
ptrace() entirely or use PID namespaces.

  reply	other threads:[~2018-02-27 23:24 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27  0:41 [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata Mickaël Salaün
2018-02-27  0:57   ` Al Viro
2018-02-27  1:23     ` Al Viro
2018-03-11 20:14       ` Mickaël Salaün
2018-02-28 16:27   ` kbuild test robot
2018-02-28 16:58   ` kbuild test robot
2018-02-27  0:41 ` [PATCH bpf-next v8 02/11] fs,security: Add a new file access type: MAY_CHROOT Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 03/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 04/11] bpf,landlock: Define an eBPF program type for Landlock hooks Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy Mickaël Salaün
2018-02-27  2:08   ` Alexei Starovoitov
2018-02-27  4:40     ` Andy Lutomirski
2018-02-27  4:54       ` Alexei Starovoitov
2018-02-27  5:20         ` Andy Lutomirski
2018-02-27  5:32           ` Alexei Starovoitov
2018-02-27 16:39             ` Andy Lutomirski
2018-02-27 17:30               ` Casey Schaufler
2018-02-27 17:36                 ` Andy Lutomirski
2018-02-27 18:03                   ` Casey Schaufler
2018-02-27 21:48               ` Mickaël Salaün
2018-04-08 13:13                 ` Mickaël Salaün
2018-04-08 21:06                   ` Andy Lutomirski
2018-04-08 22:01                     ` Mickaël Salaün
2018-04-10  4:48                       ` Alexei Starovoitov
2018-04-11 22:18                         ` Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 06/11] bpf,landlock: Add a new map type: inode Mickaël Salaün
2018-02-28 17:35   ` kbuild test robot
2018-02-27  0:41 ` [PATCH bpf-next v8 07/11] landlock: Handle filesystem access control Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions Mickaël Salaün
2018-02-27  4:17   ` Andy Lutomirski
2018-02-27  5:01     ` Andy Lutomirski
2018-02-27 22:14       ` Mickaël Salaün
2018-02-27 23:02         ` Andy Lutomirski
2018-02-27 23:23           ` Andy Lutomirski [this message]
2018-02-28  0:00             ` Mickaël Salaün
2018-02-28  0:09               ` Andy Lutomirski
2018-03-06 22:28                 ` Mickaël Salaün
2018-04-01 22:48                   ` Mickaël Salaün
2018-02-27 22:18     ` Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 09/11] bpf: Add a Landlock sandbox example Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 10/11] bpf,landlock: Add tests for Landlock Mickaël Salaün
2018-02-27  0:41 ` [PATCH bpf-next v8 11/11] landlock: Add user and kernel documentation " Mickaël Salaün
2018-02-27  4:36 ` [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing Andy Lutomirski
2018-02-27 22:03   ` Mickaël Salaün
2018-02-27 23:09     ` Andy Lutomirski
2018-03-06 22:25       ` Mickaël Salaün
2018-03-06 22:33         ` Andy Lutomirski
2018-03-06 22:46           ` Tycho Andersen
2018-03-06 23:06             ` Mickaël Salaün
2018-03-07  1:21               ` Andy Lutomirski
2018-03-08 23:51                 ` Mickaël Salaün
2018-03-08 23:53                   ` Andy Lutomirski
2018-04-01 22:04                     ` Mickaël Salaün
2018-04-02  0:39                       ` Tycho Andersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrV_BVc44YYq6g8PCpeUYuqQaooVoQSQ7Y=VpuaBshQgQg@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=acme@kernel.org \
    --cc=ast@kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=drysdale@google.com \
    --cc=ebiederm@xmission.com \
    --cc=james.l.morris@oracle.com \
    --cc=jann@thejh.net \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=mtk.manpages@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sargun@sargun.me \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=tgraf@suug.ch \
    --cc=tj@kernel.org \
    --cc=tycho@tycho.ws \
    --cc=wad@chromium.org \
    --subject='Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).