From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753932AbcH3UTX (ORCPT ); Tue, 30 Aug 2016 16:19:23 -0400 Received: from mail-ua0-f182.google.com ([209.85.217.182]:35062 "EHLO mail-ua0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751645AbcH3UTU (ORCPT ); Tue, 30 Aug 2016 16:19:20 -0400 MIME-Version: 1.0 In-Reply-To: <57C5E83F.4000102@digikod.net> References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-7-git-send-email-mic@digikod.net> <57C5E83F.4000102@digikod.net> From: Andy Lutomirski Date: Tue, 30 Aug 2016 13:18:58 -0700 Message-ID: Subject: Re: [RFC v2 06/10] landlock: Add LSM hooks To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: "Serge E. Hallyn" , David Drysdale , "kernel-hardening@lists.openwall.com" , Alexei Starovoitov , James Morris , Sargun Dhillon , Network Development , Casey Schaufler , Linux API , Kees Cook , LSM List , "linux-kernel@vger.kernel.org" , "David S . Miller" , Daniel Mack , Arnd Bergmann , Will Drewry , Paul Moore , Elena Reshetova , Daniel Borkmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7UKJRxH032285 On Tue, Aug 30, 2016 at 1:10 PM, Mickaël Salaün wrote: > > On 30/08/2016 20:56, Andy Lutomirski wrote: >> On Aug 25, 2016 12:34 PM, "Mickaël Salaün" wrote: >>> >>> Add LSM hooks which can be used by userland through Landlock (eBPF) >>> programs. This programs are limited to a whitelist of functions (cf. >>> next commit). The eBPF program context is depicted by the struct >>> landlock_data (cf. include/uapi/linux/bpf.h): >>> * hook: LSM hook ID (useful when using the same program for multiple LSM >>> hooks); >>> * cookie: the 16-bit value from the seccomp filter that triggered this >>> Landlock program; >>> * args[6]: array of LSM hook arguments. >>> >>> The LSM hook arguments can contain raw values as integers or >>> (unleakable) pointers. The only way to use the pointers are to pass them >>> to an eBPF function according to their types (e.g. the >>> bpf_landlock_cmp_fs_beneath_with_struct_file function can use a struct >>> file pointer). >>> >>> For now, there is three hooks for file system access control: >>> * file_open; >>> * file_permission; >>> * mmap_file. >>> >> >> What's the purpose of exposing struct cred * to userspace? It's >> primarily just an optimization to save a bit of RAM, and it's a >> dubious optimization at that. What are you using it for? Would it >> make more sense to use struct task_struct * or struct pid * instead? >> >> Also, exposing struct cred * has a really weird side-effect: it allows >> (maybe even encourages) checking for pointer equality between two >> struct cred * objects. Doing so will have erratic results. >> > > The pointers exposed in the ePBF context are not directly readable by an > unprivileged eBPF program thanks to the strong typing of the Landlock > context and the static eBPF verification. There is no way to leak a > kernel pointer to userspace from an unprivileged eBPF program: pointer > arithmetic and comparison are prohibited. Pointers can only be pass as > argument to dedicated eBPF functions. I'm not talking about leaking the value -- I'm talking about leaking the predicate (a == b) for two struct cred pointers. That predicate shouldn't be available because it has very odd effects. > > For now, struct cred * is simply not used by any eBPF function and then > not usable at all. It only exist here because I map the LSM hook > arguments in a generic/automatic way to the eBPF context. Maybe remove it from this patch set then? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC v2 06/10] landlock: Add LSM hooks Date: Tue, 30 Aug 2016 13:18:58 -0700 Message-ID: References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-7-git-send-email-mic@digikod.net> <57C5E83F.4000102@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Serge E. Hallyn" , David Drysdale , "kernel-hardening@lists.openwall.com" , Alexei Starovoitov , James Morris , Sargun Dhillon , Network Development , Casey Schaufler , Linux API , Kees Cook , LSM List , "linux-kernel@vger.kernel.org" , "David S . Miller" , Daniel Mack , Arnd Bergmann , Will Drewry , Paul Moore , Elena Reshetova , Da To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Return-path: In-Reply-To: <57C5E83F.4000102@digikod.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Aug 30, 2016 at 1:10 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 30/08/2016 20:56, Andy Lutomirski wrote: >> On Aug 25, 2016 12:34 PM, "Micka=C3=ABl Sala=C3=BCn" w= rote: >>> >>> Add LSM hooks which can be used by userland through Landlock (eBPF) >>> programs. This programs are limited to a whitelist of functions (cf. >>> next commit). The eBPF program context is depicted by the struct >>> landlock_data (cf. include/uapi/linux/bpf.h): >>> * hook: LSM hook ID (useful when using the same program for multiple LS= M >>> hooks); >>> * cookie: the 16-bit value from the seccomp filter that triggered this >>> Landlock program; >>> * args[6]: array of LSM hook arguments. >>> >>> The LSM hook arguments can contain raw values as integers or >>> (unleakable) pointers. The only way to use the pointers are to pass the= m >>> to an eBPF function according to their types (e.g. the >>> bpf_landlock_cmp_fs_beneath_with_struct_file function can use a struct >>> file pointer). >>> >>> For now, there is three hooks for file system access control: >>> * file_open; >>> * file_permission; >>> * mmap_file. >>> >> >> What's the purpose of exposing struct cred * to userspace? It's >> primarily just an optimization to save a bit of RAM, and it's a >> dubious optimization at that. What are you using it for? Would it >> make more sense to use struct task_struct * or struct pid * instead? >> >> Also, exposing struct cred * has a really weird side-effect: it allows >> (maybe even encourages) checking for pointer equality between two >> struct cred * objects. Doing so will have erratic results. >> > > The pointers exposed in the ePBF context are not directly readable by an > unprivileged eBPF program thanks to the strong typing of the Landlock > context and the static eBPF verification. There is no way to leak a > kernel pointer to userspace from an unprivileged eBPF program: pointer > arithmetic and comparison are prohibited. Pointers can only be pass as > argument to dedicated eBPF functions. I'm not talking about leaking the value -- I'm talking about leaking the predicate (a =3D=3D b) for two struct cred pointers. That predicate shouldn't be available because it has very odd effects. > > For now, struct cred * is simply not used by any eBPF function and then > not usable at all. It only exist here because I map the LSM hook > arguments in a generic/automatic way to the eBPF context. Maybe remove it from this patch set then? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC v2 06/10] landlock: Add LSM hooks Date: Tue, 30 Aug 2016 13:18:58 -0700 Message-ID: References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-7-git-send-email-mic@digikod.net> <57C5E83F.4000102@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <57C5E83F.4000102@digikod.net> Sender: linux-kernel-owner@vger.kernel.org To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: "Serge E. Hallyn" , David Drysdale , "kernel-hardening@lists.openwall.com" , Alexei Starovoitov , James Morris , Sargun Dhillon , Network Development , Casey Schaufler , Linux API , Kees Cook , LSM List , "linux-kernel@vger.kernel.org" , "David S . Miller" , Daniel Mack , Arnd Bergmann , Will Drewry , Paul Moore , Elena Reshetova Da List-Id: linux-api@vger.kernel.org On Tue, Aug 30, 2016 at 1:10 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 30/08/2016 20:56, Andy Lutomirski wrote: >> On Aug 25, 2016 12:34 PM, "Micka=C3=ABl Sala=C3=BCn" w= rote: >>> >>> Add LSM hooks which can be used by userland through Landlock (eBPF) >>> programs. This programs are limited to a whitelist of functions (cf. >>> next commit). The eBPF program context is depicted by the struct >>> landlock_data (cf. include/uapi/linux/bpf.h): >>> * hook: LSM hook ID (useful when using the same program for multiple LS= M >>> hooks); >>> * cookie: the 16-bit value from the seccomp filter that triggered this >>> Landlock program; >>> * args[6]: array of LSM hook arguments. >>> >>> The LSM hook arguments can contain raw values as integers or >>> (unleakable) pointers. The only way to use the pointers are to pass the= m >>> to an eBPF function according to their types (e.g. the >>> bpf_landlock_cmp_fs_beneath_with_struct_file function can use a struct >>> file pointer). >>> >>> For now, there is three hooks for file system access control: >>> * file_open; >>> * file_permission; >>> * mmap_file. >>> >> >> What's the purpose of exposing struct cred * to userspace? It's >> primarily just an optimization to save a bit of RAM, and it's a >> dubious optimization at that. What are you using it for? Would it >> make more sense to use struct task_struct * or struct pid * instead? >> >> Also, exposing struct cred * has a really weird side-effect: it allows >> (maybe even encourages) checking for pointer equality between two >> struct cred * objects. Doing so will have erratic results. >> > > The pointers exposed in the ePBF context are not directly readable by an > unprivileged eBPF program thanks to the strong typing of the Landlock > context and the static eBPF verification. There is no way to leak a > kernel pointer to userspace from an unprivileged eBPF program: pointer > arithmetic and comparison are prohibited. Pointers can only be pass as > argument to dedicated eBPF functions. I'm not talking about leaking the value -- I'm talking about leaking the predicate (a =3D=3D b) for two struct cred pointers. That predicate shouldn't be available because it has very odd effects. > > For now, struct cred * is simply not used by any eBPF function and then > not usable at all. It only exist here because I map the LSM hook > arguments in a generic/automatic way to the eBPF context. Maybe remove it from this patch set then? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <57C5E83F.4000102@digikod.net> References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-7-git-send-email-mic@digikod.net> <57C5E83F.4000102@digikod.net> From: Andy Lutomirski Date: Tue, 30 Aug 2016 13:18:58 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: [RFC v2 06/10] landlock: Add LSM hooks To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: "Serge E. Hallyn" , David Drysdale , "kernel-hardening@lists.openwall.com" , Alexei Starovoitov , James Morris , Sargun Dhillon , Network Development , Casey Schaufler , Linux API , Kees Cook , LSM List , "linux-kernel@vger.kernel.org" , "David S . Miller" , Daniel Mack , Arnd Bergmann , Will Drewry , Paul Moore , Elena Reshetova , Daniel Borkmann List-ID: On Tue, Aug 30, 2016 at 1:10 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 30/08/2016 20:56, Andy Lutomirski wrote: >> On Aug 25, 2016 12:34 PM, "Micka=C3=ABl Sala=C3=BCn" w= rote: >>> >>> Add LSM hooks which can be used by userland through Landlock (eBPF) >>> programs. This programs are limited to a whitelist of functions (cf. >>> next commit). The eBPF program context is depicted by the struct >>> landlock_data (cf. include/uapi/linux/bpf.h): >>> * hook: LSM hook ID (useful when using the same program for multiple LS= M >>> hooks); >>> * cookie: the 16-bit value from the seccomp filter that triggered this >>> Landlock program; >>> * args[6]: array of LSM hook arguments. >>> >>> The LSM hook arguments can contain raw values as integers or >>> (unleakable) pointers. The only way to use the pointers are to pass the= m >>> to an eBPF function according to their types (e.g. the >>> bpf_landlock_cmp_fs_beneath_with_struct_file function can use a struct >>> file pointer). >>> >>> For now, there is three hooks for file system access control: >>> * file_open; >>> * file_permission; >>> * mmap_file. >>> >> >> What's the purpose of exposing struct cred * to userspace? It's >> primarily just an optimization to save a bit of RAM, and it's a >> dubious optimization at that. What are you using it for? Would it >> make more sense to use struct task_struct * or struct pid * instead? >> >> Also, exposing struct cred * has a really weird side-effect: it allows >> (maybe even encourages) checking for pointer equality between two >> struct cred * objects. Doing so will have erratic results. >> > > The pointers exposed in the ePBF context are not directly readable by an > unprivileged eBPF program thanks to the strong typing of the Landlock > context and the static eBPF verification. There is no way to leak a > kernel pointer to userspace from an unprivileged eBPF program: pointer > arithmetic and comparison are prohibited. Pointers can only be pass as > argument to dedicated eBPF functions. I'm not talking about leaking the value -- I'm talking about leaking the predicate (a =3D=3D b) for two struct cred pointers. That predicate shouldn't be available because it has very odd effects. > > For now, struct cred * is simply not used by any eBPF function and then > not usable at all. It only exist here because I map the LSM hook > arguments in a generic/automatic way to the eBPF context. Maybe remove it from this patch set then? --Andy