Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5329063ybv; Tue, 11 Feb 2020 13:37:26 -0800 (PST) X-Google-Smtp-Source: APXvYqy6xestiX2SE98tQBF/JS9TWjrGFfeZXbDSgLulZmBpSJ/iPWwVIqsfMkn0KtGA/67FzXVN X-Received: by 2002:aca:4994:: with SMTP id w142mr4050045oia.178.1581457046076; Tue, 11 Feb 2020 13:37:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581457046; cv=none; d=google.com; s=arc-20160816; b=DEIOy7N0OB5UqukkqEoY7QSS26jz/BrwHLNQG5rkbPVdi8K9AJF24/RcPUa8trsixm Z/k7WYk7di5+0LamKxWhAwpL9RD6JxFFa3HboUokX112ay0MBbluPh5ECG3rKNwD+QIR /v2oaX+iv2V5f7+u8KMr0yn8X4ULEmJ+0Mn2oSG6qHCuSsrcRYMtFhGKLI6hiiy99pzI k1fypjmR7zOthrmlRWDXcbElC0JuPXifI4YuFSPk4XW8FhIcvmUAhSqXPv/TF23WEjrO 5jNVGvf+qe7/pV60QPkBFL5j4aia1re6GHeP/98Pv7P0fsByT5DnFWA1qeo/u/AAVMMr CV1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=HF3YzYTi/Ks+MTJab6l7yP1LaB89T8PPJLlG/hEhges=; b=vjSuQ72TnLgQzF0PtWApaY04AIjg9m2ZBIuTLtJR1UCUvorFXyyiy1wepj34qur2cx 39WT2Ww8ijXiYkknlgH2hy+X79eV+p8GCZbKdctRkbyvtDpw4erZof96seAUsR0sC+KC asO9b2K8eJU6pa6N+wgy6p84yoJI+T+hsfXqX2m6zxlCDCQ70Wa01A4qg321XkIOAlzv p1T+U16zTuDRth/cnX+5piu/Y7cVU0euOE61gC3jFXlly2PPUoiri+/pfwwl92qgUr4A uVbIoV2FDZahSuMcxkKITzoXW9LRE/lpK/7qDEb1uuzOiEDDx5my5lTtEPkbsHXsudnN CJXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=EyplU89Q; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a12si2146725oie.87.2020.02.11.13.37.14; Tue, 11 Feb 2020 13:37:26 -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=@google.com header.s=20161025 header.b=EyplU89Q; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731437AbgBKSoc (ORCPT + 99 others); Tue, 11 Feb 2020 13:44:32 -0500 Received: from mail-oi1-f169.google.com ([209.85.167.169]:43912 "EHLO mail-oi1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730669AbgBKSoc (ORCPT ); Tue, 11 Feb 2020 13:44:32 -0500 Received: by mail-oi1-f169.google.com with SMTP id p125so13766319oif.10 for ; Tue, 11 Feb 2020 10:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HF3YzYTi/Ks+MTJab6l7yP1LaB89T8PPJLlG/hEhges=; b=EyplU89QVtIzl2H6+9ficfFQTF1vZAYEN53+R6TJ5NCz3uz+jNHjSriM366bGhUzpQ Zqu994vE7Ze0ZYuEQN+YncFcuvFWd22BHgpjgI4rzGNAff3PgSsRdZkRd1EU7hAwHhok EergH+heTb+5qyBgqhjOajSmFD6w7sQnCRuileRb1hqPKOy7Lj5M89WKOurMpOVx5Kw7 7JV8hn3fVoJ5dqsp8HNRhPrWJirRS0wVrXcSgpNr8GrMKB52gFh9IV3OzFSOiu7HFQFZ zqUltX9NxqOHdAZ7z8iYAtiXoAzWJb24IPffAR9NYGmEI2bAYv4NbV8fVhpJOueAfmws Uk9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HF3YzYTi/Ks+MTJab6l7yP1LaB89T8PPJLlG/hEhges=; b=W5FklzMmbqUQzxUE03HNMaFGDwDtWWqpkycVhUTUTE6EHjCovC+PjEVaYLpWALKPQe FJ8jDzFr41o7V1yqYrumqRP4QkZoMyd+KEsr1MTkxsVIQkb13SMfazw6F9rQMsnJvZXS 7XqTVaBPGZivjaEBnGGYJMfo2QlFhIQpv286nCbZ+EGLDDJMv047A5sv6mLuN5VcIapE E4tQ2RwU0EEJ6NvdkgF/dV1GQxOkvJAoWbVO7jGjHWfYCrUJv+Y1//IPAXhZT5YoILDW s2UvAJjE7RBFLR7014JcSudb1yMmAui9wdqcEgRrAC4ApOdUSe+ijnGxMCmRHvmUN07Z lU2g== X-Gm-Message-State: APjAAAVnf54etqK2IJbOJen+6KpK+EWElp/dCZxXWiaEuaqYVn2aqA0q lB1GeP0y6FbuMY0iOvIQ/+Y/0NWUSWy8ivZQ+ztCswHKIaY= X-Received: by 2002:aca:b187:: with SMTP id a129mr3807804oif.175.1581446671435; Tue, 11 Feb 2020 10:44:31 -0800 (PST) MIME-Version: 1.0 References: <20200123152440.28956-1-kpsingh@chromium.org> <20200123152440.28956-5-kpsingh@chromium.org> <20200211031208.e6osrcathampoog7@ast-mbp> <20200211124334.GA96694@google.com> <20200211175825.szxaqaepqfbd2wmg@ast-mbp> In-Reply-To: <20200211175825.szxaqaepqfbd2wmg@ast-mbp> From: Jann Horn Date: Tue, 11 Feb 2020 19:44:05 +0100 Message-ID: Subject: BPF LSM and fexit [was: [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM] To: Alexei Starovoitov , KP Singh Cc: kernel list , bpf@vger.kernel.org, linux-security-module , Brendan Jackman , Florent Revest , Thomas Garnier , Alexei Starovoitov , Daniel Borkmann , James Morris , Kees Cook , Thomas Garnier , Michael Halcrow , Paul Turner , Brendan Gregg , Matthew Garrett , Christian Brauner , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Florent Revest , Brendan Jackman , "Serge E. Hallyn" , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 11, 2020 at 6:58 PM Alexei Starovoitov wrote: > On Tue, Feb 11, 2020 at 01:43:34PM +0100, KP Singh wrote: [...] > > * When using the semantic provided by fexit, the BPF LSM program will > > always be executed and will be able to override / clobber the > > decision of LSMs which appear before it in the ordered list. This > > semantic is very different from what we currently have (i.e. the BPF > > LSM hook is only called if all the other LSMs allow the action) and > > seems to be bypassing the LSM framework. > > It that's a concern it's trivial to add 'if (RC == 0)' check to fexit > trampoline generator specific to lsm progs. [...] > Using fexit mechanism and bpf_sk_storage generalization is > all that is needed. None of it should touch security/*. If I understand your suggestion correctly, that seems like a terrible idea to me from the perspective of inspectability and debuggability. If at runtime, a function can branch off elsewhere to modify its decision, I want to see that in the source code. If someone e.g. changes the parameters or the locking rules around a security hook, how are they supposed to understand the implications if that happens through some magic fexit trampoline that is injected at runtime?