From: Alexei Starovoitov <alexei.starovoitov@gmail.com> To: Casey Schaufler <casey@schaufler-ca.com> Cc: "Mickaël Salaün" <mic@digikod.net>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Andy Lutomirski" <luto@amacapital.net>, "Daniel Borkmann" <daniel@iogearbox.net>, "David Drysdale" <drysdale@google.com>, "Florent Revest" <revest@chromium.org>, "James Morris" <jmorris@namei.org>, "Jann Horn" <jann@thejh.net>, "John Johansen" <john.johansen@canonical.com>, "Jonathan Corbet" <corbet@lwn.net>, "Kees Cook" <keescook@chromium.org>, "KP Singh" <kpsingh@chromium.org>, "Michael Kerrisk" <mtk.manpages@gmail.com>, "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>, "Paul Moore" <paul@paul-moore.com>, "Sargun Dhillon" <sargun@sargun.me>, "Serge E . Hallyn" <serge@hallyn.com>, "Shuah Khan" <shuah@kernel.org>, "Stephen Smalley" <sds@tycho.nsa.gov>, "Tejun Heo" <tj@kernel.org>, "Tetsuo Handa" <penguin-kernel@I-love.SAKURA.ne.jp>, "Tycho Andersen" <tycho@tycho.ws>, "Will Drewry" <wad@chromium.org>, bpf@vger.kernel.org, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Date: Tue, 5 Nov 2019 11:31:32 -0800 [thread overview] Message-ID: <20191105193130.qam2eafnmgvrvjwk@ast-mbp.dhcp.thefacebook.com> (raw) In-Reply-To: <c5c6b433-7e6a-c8f8-f063-e704c3df4cc6@schaufler-ca.com> On Tue, Nov 05, 2019 at 09:55:42AM -0800, Casey Schaufler wrote: > On 11/5/2019 9:18 AM, Alexei Starovoitov wrote: > > On Mon, Nov 04, 2019 at 06:21:43PM +0100, Mickaël Salaün wrote: > >> Add a first Landlock hook that can be used to enforce a security policy > >> or to audit some process activities. For a sandboxing use-case, it is > >> needed to inform the kernel if a task can legitimately debug another. > >> ptrace(2) can also be used by an attacker to impersonate another task > >> and remain undetected while performing malicious activities. > >> > >> Using ptrace(2) and related features on a target process can lead to a > >> privilege escalation. A sandboxed task must then be able to tell the > >> kernel if another task is more privileged, via ptrace_may_access(). > >> > >> Signed-off-by: Mickaël Salaün <mic@digikod.net> > > ... > >> +static int check_ptrace(struct landlock_domain *domain, > >> + struct task_struct *tracer, struct task_struct *tracee) > >> +{ > >> + struct landlock_hook_ctx_ptrace ctx_ptrace = { > >> + .prog_ctx = { > >> + .tracer = (uintptr_t)tracer, > >> + .tracee = (uintptr_t)tracee, > >> + }, > >> + }; > > So you're passing two kernel pointers obfuscated as u64 into bpf program > > yet claiming that the end goal is to make landlock unprivileged?! > > The most basic security hole in the tool that is aiming to provide security. > > > > I think the only way bpf-based LSM can land is both landlock and KRSI > > developers work together on a design that solves all use cases. BPF is capable > > to be a superset of all existing LSMs > > I can't agree with this. Nope. There are many security models > for which BPF introduces excessive complexity. You don't need > or want the generality of a general purpose programming language > to implement Smack or TOMOYO. Or a simple Bell & LaPadula for > that matter. SELinux? I can't imagine anyone trying to do that > in eBPF, although I'm willing to be surprised. Being able to > enforce a policy isn't the only criteria for an LSM. what are the other criteria? > It's got > to perform well and integrate with the rest of the system. what do you mean by that? > I see many issues with a BPF <-> vfs interface. There is no such interface today. What do you have in mind? > the mechanisms needed for the concerns of the day. Ideally, > we should be able to drop mechanisms when we decide that they > no longer add value. Exactly. bpf-based lsm must not add to kernel abi.
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <alexei.starovoitov@gmail.com> To: Casey Schaufler <casey@schaufler-ca.com> Cc: "Mickaël Salaün" <mic@digikod.net>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Andy Lutomirski" <luto@amacapital.net>, "Daniel Borkmann" <daniel@iogearbox.net>, "David Drysdale" <drysdale@google.com>, "Florent Revest" <revest@chromium.org>, "James Morris" <jmorris@namei.org>, "Jann Horn" <jann@thejh.net>, "John Johansen" <john.johansen@canonical.com>, "Jonathan Corbet" <corbet@lwn.net>, "Kees Cook" <keescook@chromium.org>, "KP Singh" <kpsingh@chromium.org>, "Michael Kerrisk" <mtk.manpages@gmail.com>, "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>, "Paul Moore" <paul@paul-moore.com>, "Sargun Dhillon" <sargun@sargun.me>, "Serge E . Hallyn" <serge@hallyn.com>, "Shuah Khan" <shuah@kernel.org>, "Stephen Smalley" <sds@tych> Subject: Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Date: Tue, 5 Nov 2019 11:31:32 -0800 [thread overview] Message-ID: <20191105193130.qam2eafnmgvrvjwk@ast-mbp.dhcp.thefacebook.com> (raw) In-Reply-To: <c5c6b433-7e6a-c8f8-f063-e704c3df4cc6@schaufler-ca.com> On Tue, Nov 05, 2019 at 09:55:42AM -0800, Casey Schaufler wrote: > On 11/5/2019 9:18 AM, Alexei Starovoitov wrote: > > On Mon, Nov 04, 2019 at 06:21:43PM +0100, Mickaël Salaün wrote: > >> Add a first Landlock hook that can be used to enforce a security policy > >> or to audit some process activities. For a sandboxing use-case, it is > >> needed to inform the kernel if a task can legitimately debug another. > >> ptrace(2) can also be used by an attacker to impersonate another task > >> and remain undetected while performing malicious activities. > >> > >> Using ptrace(2) and related features on a target process can lead to a > >> privilege escalation. A sandboxed task must then be able to tell the > >> kernel if another task is more privileged, via ptrace_may_access(). > >> > >> Signed-off-by: Mickaël Salaün <mic@digikod.net> > > ... > >> +static int check_ptrace(struct landlock_domain *domain, > >> + struct task_struct *tracer, struct task_struct *tracee) > >> +{ > >> + struct landlock_hook_ctx_ptrace ctx_ptrace = { > >> + .prog_ctx = { > >> + .tracer = (uintptr_t)tracer, > >> + .tracee = (uintptr_t)tracee, > >> + }, > >> + }; > > So you're passing two kernel pointers obfuscated as u64 into bpf program > > yet claiming that the end goal is to make landlock unprivileged?! > > The most basic security hole in the tool that is aiming to provide security. > > > > I think the only way bpf-based LSM can land is both landlock and KRSI > > developers work together on a design that solves all use cases. BPF is capable > > to be a superset of all existing LSMs > > I can't agree with this. Nope. There are many security models > for which BPF introduces excessive complexity. You don't need > or want the generality of a general purpose programming language > to implement Smack or TOMOYO. Or a simple Bell & LaPadula for > that matter. SELinux? I can't imagine anyone trying to do that > in eBPF, although I'm willing to be surprised. Being able to > enforce a policy isn't the only criteria for an LSM. what are the other criteria? > It's got > to perform well and integrate with the rest of the system. what do you mean by that? > I see many issues with a BPF <-> vfs interface. There is no such interface today. What do you have in mind? > the mechanisms needed for the concerns of the day. Ideally, > we should be able to drop mechanisms when we decide that they > no longer add value. Exactly. bpf-based lsm must not add to kernel abi.
next prev parent reply other threads:[~2019-11-05 19:31 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-04 17:21 [PATCH bpf-next v13 0/7] Landlock LSM Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 1/7] bpf,landlock: Define an eBPF program type for Landlock hooks Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 2/7] landlock: Add the management of domains Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 3/7] landlock,seccomp: Apply Landlock programs to process hierarchy Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-05 17:18 ` Alexei Starovoitov 2019-11-05 17:18 ` Alexei Starovoitov 2019-11-05 17:55 ` Casey Schaufler 2019-11-05 17:55 ` Casey Schaufler 2019-11-05 19:31 ` Alexei Starovoitov [this message] 2019-11-05 19:31 ` Alexei Starovoitov 2019-11-05 19:55 ` Casey Schaufler 2019-11-05 19:55 ` Casey Schaufler 2019-11-05 21:54 ` Alexei Starovoitov 2019-11-05 21:54 ` Alexei Starovoitov 2019-11-05 22:32 ` Casey Schaufler 2019-11-05 22:32 ` Casey Schaufler 2019-11-05 18:01 ` Mickaël Salaün 2019-11-05 18:01 ` Mickaël Salaün 2019-11-05 19:34 ` Alexei Starovoitov 2019-11-05 19:34 ` Alexei Starovoitov 2019-11-05 22:18 ` Mickaël Salaün 2019-11-05 22:18 ` Mickaël Salaün 2019-11-06 10:06 ` KP Singh 2019-11-06 10:06 ` KP Singh 2019-11-06 16:55 ` Mickaël Salaün 2019-11-06 16:55 ` Mickaël Salaün 2019-11-06 21:45 ` KP Singh 2019-11-06 21:45 ` KP Singh 2019-11-08 14:08 ` Mickaël Salaün 2019-11-08 14:08 ` Mickaël Salaün 2019-11-08 14:34 ` Daniel Borkmann 2019-11-08 14:34 ` Daniel Borkmann 2019-11-08 15:39 ` Mickaël Salaün 2019-11-08 15:39 ` Mickaël Salaün 2019-11-08 15:27 ` KP Singh 2019-11-08 15:27 ` KP Singh 2019-11-06 10:15 ` KP Singh 2019-11-06 10:15 ` KP Singh 2019-11-06 16:58 ` Mickaël Salaün 2019-11-06 16:58 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 5/7] bpf,landlock: Add task_landlock_ptrace_ancestor() helper Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 6/7] bpf,landlock: Add tests for the Landlock ptrace program type Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 7/7] landlock: Add user and kernel documentation for Landlock Mickaël Salaün 2019-11-04 17:21 ` Mickaël Salaün
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=20191105193130.qam2eafnmgvrvjwk@ast-mbp.dhcp.thefacebook.com \ --to=alexei.starovoitov@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=daniel@iogearbox.net \ --cc=drysdale@google.com \ --cc=jann@thejh.net \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=kpsingh@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mic@digikod.net \ --cc=mickael.salaun@ssi.gouv.fr \ --cc=mtk.manpages@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=revest@chromium.org \ --cc=sargun@sargun.me \ --cc=sds@tycho.nsa.gov \ --cc=serge@hallyn.com \ --cc=shuah@kernel.org \ --cc=tj@kernel.org \ --cc=tycho@tycho.ws \ --cc=wad@chromium.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.