From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754289AbcHZO5t (ORCPT ); Fri, 26 Aug 2016 10:57:49 -0400 Received: from mail-ua0-f179.google.com ([209.85.217.179]:34156 "EHLO mail-ua0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752158AbcHZO5p (ORCPT ); Fri, 26 Aug 2016 10:57:45 -0400 MIME-Version: 1.0 In-Reply-To: <57BEFC65.3090305@digikod.net> References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-9-git-send-email-mic@digikod.net> <57BEFC65.3090305@digikod.net> From: Andy Lutomirski Date: Fri, 26 Aug 2016 07:57:18 -0700 Message-ID: Subject: Re: [RFC v2 08/10] landlock: Handle file system comparisons To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: "Eric W. Biederman" , LKML , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Will Drewry , kernel-hardening , Linux API , LSM List , Network Development 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 u7QEx0M8011444 On Thu, Aug 25, 2016 at 7:10 AM, Mickaël Salaün wrote: > > On 25/08/2016 13:12, Andy Lutomirski wrote: >> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün wrote: >>> Add eBPF functions to compare file system access with a Landlock file >>> system handle: >>> * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) >>> This function allows to compare the dentry, inode, device or mount >>> point of the currently accessed file, with a reference handle. >>> * bpf_landlock_cmp_fs_beneath_with_struct_file(opt, map, map_op, file) >>> This function allows an eBPF program to check if the current accessed >>> file is the same or in the hierarchy of a reference handle. >>> >>> The goal of file system handle is to abstract kernel objects such as a >>> struct file or a struct inode. Userland can create this kind of handle >>> thanks to the BPF_MAP_UPDATE_ELEM command. The element is a struct >>> landlock_handle containing the handle type (e.g. >>> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) and a file descriptor. This could >>> also be any descriptions able to match a struct file or a struct inode >>> (e.g. path or glob string). >> >> This needs Eric's opinion. >> >> Also, where do all the struct file *'s get stashed? Are they >> preserved in the arraymap? What prevents reference cycles or absurdly >> large numbers of struct files getting pinned? > > Yes, the struct file are kept in the arraymap and dropped when there is > no more reference on them. Currently, the limitations are the maximum > number of open file descriptors referring to an arraymap and the maximum > number of eBPF Landlock programs loaded in a process > (LANDLOCK_PROG_LIST_MAX_PAGES in kernel/seccomp.c). > > What kind of reference cycles have you in mind? Shoving evil things into the arraymaps, e.g. unix sockets with SCM_RIGHTS messages pending, eBPF program references, the arraymap fd itself, another arraymap fd, etc. > > It probably needs another limit for kernel object references as well. > What is the best option here? Add another static limitation or use an > existing one? Dunno. If RLIMIT_FILE could be made to work, that would be nice. --Andy