From: "Mickaël Salaün" <mic@digikod.net> To: Daniel Borkmann <daniel@iogearbox.net> Cc: "KP Singh" <kpsingh@chromium.org>, "Alexei Starovoitov" <alexei.starovoitov@gmail.com>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Andy Lutomirski" <luto@amacapital.net>, "Casey Schaufler" <casey@schaufler-ca.com>, "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>, "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: Fri, 8 Nov 2019 16:39:55 +0100 Message-ID: <78b75ea3-3a7c-103c-ee00-a9c6c41bcd9c@digikod.net> (raw) In-Reply-To: <5d0f1dc5-5a99-bd6a-4acc-0cdcd062a0c9@iogearbox.net> On 08/11/2019 15:34, Daniel Borkmann wrote: > On 11/8/19 3:08 PM, Mickaël Salaün wrote: >> On 06/11/2019 22:45, KP Singh wrote: >>> On 06-Nov 17:55, Mickaël Salaün wrote: >>>> On 06/11/2019 11:06, KP Singh wrote: >>>>> On 05-Nov 11:34, Alexei Starovoitov wrote: >>>>>> On Tue, Nov 05, 2019 at 07:01:41PM +0100, Mickaël Salaün wrote: >>>>>>> On 05/11/2019 18:18, Alexei Starovoitov wrote: > [...] >>> * Use a single BPF program type; this is necessary for a key requirement >>> of KRSI, i.e. runtime instrumentation. The upcoming prototype should >>> illustrate how this works for KRSI - note that it’s possible to vary >>> the context types exposed by different hooks. >> >> Why a single BPF program type? Do you mean *attach* types? Landlock only >> use one program type, but will use multiple attach types. >> >> Why do you think it is necessary for KRSI or for runtime instrumentation? >> >> If it is justified, it could be a dedicated program attach type (e.g. >> BPF_LANDLOCK_INTROSPECTION). >> >> What is the advantage to have the possibility to vary the context types >> over dedicated *typed* contexts? I don't see any advantages, but at >> least one main drawback: to require runtime checks (when helpers use >> this generic context) instead of load time checks (thanks to static type >> checking of the context). > > Lets take security_sock_rcv_skb(struct sock *sk, struct sk_buff *skb) > as one specific example here: the running kernel has its own internal > btf_vmlinux and therefore a complete description of itself. From verifier > side we can retrieve & introspect the security_sock_rcv_skb signatue OK, this is indeed the signature defined by the kernel API. What happen if this API change (e.g. if struct sock is replaced with a struct sock_meta)? > and > thus know that the given BPF attachment point has struct sock and struct > sk_buff as input arguments How does the verifier know a given BPF attachment point for a program without relying on its type or attach type? How and where is registered this mapping? To say it another way, if there is no way to differentiate two program targeting different hook, I don't understand how the verifier could check if a given program can legitimately call a helper which could read the tracer and tracee fields (legitimate for a ptrace hook), whereas this program may be attached to a sock_rcv_skb hook (and there is no way to know that). > which can then be accessed generically by the > prog in order to allow sk_filter_trim_cap() to pass or to drop the skb. > The same generic approach can be done for many of the other lsm hooks, so > single program type would be enough there and context is derived > automatically, > no dedicated extra context per attach type would be needed and no runtime > checks as you mentioned above since its still all asserted at verification > time. I mentioned runtime check because I though a helper should handle the case when it doesn't make sense for a program attached to a specific point/hook (e.g. ptrace) to use an input argument (e.g. sk) defined for another point/hook (e.g. sock_rcv_skb). > > Thanks, > Daniel > Thanks for this explanation Daniel.
next prev parent reply index Thread overview: 26+ 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 ` [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 ` [PATCH bpf-next v13 2/7] landlock: Add the management of domains 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 ` [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Mickaël Salaün 2019-11-05 17:18 ` Alexei Starovoitov 2019-11-05 17:55 ` Casey Schaufler 2019-11-05 19:31 ` Alexei Starovoitov 2019-11-05 19:55 ` Casey Schaufler 2019-11-05 21:54 ` Alexei Starovoitov 2019-11-05 22:32 ` Casey Schaufler 2019-11-05 18:01 ` Mickaël Salaün 2019-11-05 19:34 ` Alexei Starovoitov 2019-11-05 22:18 ` Mickaël Salaün 2019-11-06 10:06 ` KP Singh 2019-11-06 16:55 ` Mickaël Salaün 2019-11-06 21:45 ` KP Singh 2019-11-08 14:08 ` Mickaël Salaün 2019-11-08 14:34 ` Daniel Borkmann 2019-11-08 15:39 ` Mickaël Salaün [this message] 2019-11-08 15:27 ` KP Singh 2019-11-06 10:15 ` KP Singh 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 ` [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 ` [PATCH bpf-next v13 7/7] landlock: Add user and kernel documentation for Landlock 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=78b75ea3-3a7c-103c-ee00-a9c6c41bcd9c@digikod.net \ --to=mic@digikod.net \ --cc=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=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: link
BPF Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \ bpf@vger.kernel.org public-inbox-index bpf Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.bpf AGPL code for this site: git clone https://public-inbox.org/public-inbox.git