Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp4077693rwn; Sun, 11 Sep 2022 04:52:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR7JILOPo75LH64v/1CFrkPTDPty+iLsFOeA3Jfj0lJO1+jt1BU56JJ2T4Bvpn+HeAvUQGBT X-Received: by 2002:a17:903:41cc:b0:176:d89d:63e3 with SMTP id u12-20020a17090341cc00b00176d89d63e3mr21933830ple.31.1662897120283; Sun, 11 Sep 2022 04:52:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662897120; cv=none; d=google.com; s=arc-20160816; b=JgCmNfxNKqUn0HmDJhOdjEbHaBzgoz7ZCeWWsAcTmAYPpWQkBg3Rlx1a2RfvfP+rYE nHqcIaY8FLj5DgPavRSDJyENfQq5yL9lX/anb4hv2uePeUdIJP1xmfXTVt02TCF5bXrI WMqqTJtFB0/YDiZoA5VPMx6MzXAYUUCTIsClbZaZ2xhclY2SXzdNIffq80FACKbRkNHr CcOECHUROzO9cemIKW/qjqzn07U5SIqxaeGfAQJ2rgmfeAe4Wl5LG8EZzbcYzx8oRE3Z IrQZy6wesWaFq6nf7gn23Qq6wvZMlv36ekYtRxF4qzTq+Jr7vN1rJyStvtTcb39LL4kO U4ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=9YjLfLElZSqVBA/2YmE91lOjhAwdiqZbrltX6v0n9So=; b=cprks/mhk5Z0VDBvtHgijkCpSvZDfIohpHAQ/PCRg+6aLQpH5vxVcGbcj2KmcTvS2K WP+Jmuic9ItJpQIyf0AyJfzyAH3aR1+MktcZDf59a1LuixRIEdDB8N51E/In6VPi39pn enhBUCrPurKM5X74GbHw0SuAceIAKxJ5OTYPN8+/xNgzPzGfgsNG6DO8JfAYsGcguJ6F cFq186esrFEodGvnTfJ6/5rfkA6iVRw7ZvATOhZNm1TsXqYwQ33E9EUuiXcX0EELqHw1 9j69ru8RL7pRDeO0X0YsDBEYI0vCE9AtGaeyDEf1aSeSQNNzXaNUymZGlRnltkhOBVjr kLtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dO9a1bCj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f4-20020a655904000000b004303da67c67si6015556pgu.370.2022.09.11.04.51.49; Sun, 11 Sep 2022 04:52:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dO9a1bCj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230407AbiIKLlI (ORCPT + 99 others); Sun, 11 Sep 2022 07:41:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230325AbiIKLlE (ORCPT ); Sun, 11 Sep 2022 07:41:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61B0E399CC for ; Sun, 11 Sep 2022 04:41:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1BCE7B80B31 for ; Sun, 11 Sep 2022 11:41:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD816C4347C for ; Sun, 11 Sep 2022 11:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662896460; bh=mfC/DzcLdVbiyBOdkdFzHVkQuK8qpwvJhFQkQNsjoBc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dO9a1bCjZWZa+j3+YvkaHc7afn0eZ9xJRUUkbpjJwNa/BYKyox7+5L8Yifx9OJPm9 xMLqBGhuNZ+T31UE2LZrDlYWarc+dQCNZSHWZad6WxBTvSBYyYtZ0RK3f7KOeCDUSW dlg5T4Shm1GiDFVY9tJY12iLzzPf/o0ThJBjK5PE7R2kMOvLxGDCHCs9IXsF5pjzNQ P/R2OdrYWxNWCDC/URJu5xhtP/D2zLgnoV4xggnx8yVQeLADKs052ntgWzXyw6BZag g+I0CSxGWEleFvbhU93i0yzauY4cAUAveQQI95Y0peM1f0q0ClLTAFlZ+YDCD5WhLk PbF8/UPo+gLQQ== Received: by mail-lf1-f47.google.com with SMTP id bt10so10467054lfb.1 for ; Sun, 11 Sep 2022 04:41:00 -0700 (PDT) X-Gm-Message-State: ACgBeo21nbBE1FGlYF+5mYVjXgQJp973X3bwvMTperweHax8dnTThSCd xAFYG0jwqUJFbCH0pEXmEV6eDoi2KsLBZN9svyxdaQ== X-Received: by 2002:aa7:cd14:0:b0:44e:2335:fb90 with SMTP id b20-20020aa7cd14000000b0044e2335fb90mr18029880edw.152.1662896448217; Sun, 11 Sep 2022 04:40:48 -0700 (PDT) MIME-Version: 1.0 References: <20220909120736.1027040-1-roberto.sassu@huaweicloud.com> <20220909120736.1027040-8-roberto.sassu@huaweicloud.com> In-Reply-To: <20220909120736.1027040-8-roberto.sassu@huaweicloud.com> From: KP Singh Date: Sun, 11 Sep 2022 13:40:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v17 07/12] bpf: Add bpf_verify_pkcs7_signature() kfunc To: Roberto Sassu Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, sdf@google.com, haoluo@google.com, jolsa@kernel.org, mykolal@fb.com, dhowells@redhat.com, jarkko@kernel.org, rostedt@goodmis.org, mingo@redhat.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, shuah@kernel.org, bpf@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, deso@posteo.net, memxor@gmail.com, Roberto Sassu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 9, 2022 at 2:09 PM Roberto Sassu wrote: > > From: Roberto Sassu > > Add the bpf_verify_pkcs7_signature() kfunc, to give eBPF security modules > the ability to check the validity of a signature against supplied data, by > using user-provided or system-provided keys as trust anchor. > > The new kfunc makes it possible to enforce mandatory policies, as eBPF > programs might be allowed to make security decisions only based on data > sources the system administrator approves. > > The caller should provide the data to be verified and the signature as eBPF > dynamic pointers (to minimize the number of parameters) and a bpf_key > structure containing a reference to the keyring with keys trusted for > signature verification, obtained from bpf_lookup_user_key() or > bpf_lookup_system_key(). > > For bpf_key structures obtained from the former lookup function, > bpf_verify_pkcs7_signature() completes the permission check deferred by > that function by calling key_validate(). key_task_permission() is already > called by the PKCS#7 code. > > Signed-off-by: Roberto Sassu > Acked-by: KP Singh > --- > kernel/trace/bpf_trace.c | 45 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index ab183dbaa8d1..9df53c40cffd 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -1294,12 +1294,57 @@ void bpf_key_put(struct bpf_key *bkey) > kfree(bkey); > } > > +#ifdef CONFIG_SYSTEM_DATA_VERIFICATION > +/** > + * bpf_verify_pkcs7_signature - verify a PKCS#7 signature > + * @data_ptr: data to verify > + * @sig_ptr: signature of the data > + * @trusted_keyring: keyring with keys trusted for signature verification > + * > + * Verify the PKCS#7 signature *sig_ptr* against the supplied *data_ptr* > + * with keys in a keyring referenced by *trusted_keyring*. > + * > + * Return: 0 on success, a negative value on error. > + */ > +int bpf_verify_pkcs7_signature(struct bpf_dynptr_kern *data_ptr, > + struct bpf_dynptr_kern *sig_ptr, > + struct bpf_key *trusted_keyring) > +{ > + int ret; > + > + if (trusted_keyring->has_ref) { > + /* > + * Do the permission check deferred in bpf_lookup_user_key(). > + * See bpf_lookup_user_key() for more details. > + * > + * A call to key_task_permission() here would be redundant, as > + * it is already done by keyring_search() called by > + * find_asymmetric_key(). > + */ > + ret = key_validate(trusted_keyring->key); > + if (ret < 0) > + return ret; > + } > + > + return verify_pkcs7_signature(data_ptr->data, > + bpf_dynptr_get_size(data_ptr), > + sig_ptr->data, > + bpf_dynptr_get_size(sig_ptr), > + trusted_keyring->key, > + VERIFYING_UNSPECIFIED_SIGNATURE, NULL, > + NULL); > +} This seems to work if the data that needs to be verified and the signature is allocated onto the map. For BPF program signing, the signature will be void * pointer (and length) in a struct in the kernel +++ b/include/uapi/linux/bpf.h @@ -1383,6 +1383,8 @@ union bpf_attr { __aligned_u64 fd_array; /* array of FDs */ __aligned_u64 core_relos; __u32 core_relo_rec_size; /* sizeof(struct bpf_core_relo) */ + __aligned_u64 signature; + __u32 signature_size; }; Something like this in the bpf_prog_aux struct which is passed to security_bpf_prog_alloc. Now creating a dynptr to use with this kfunc does not work: bpf_dynptr_from_mem(aux->signature, aux->signature_size, 0, &sig_ptr); So one has to copy kernel data into a map and then create dynptrs. Would you be able to update the dynptr logic to handle this case too? (follow up is okay too). - KP > +#endif /* CONFIG_SYSTEM_DATA_VERIFICATION */ > + > __diag_pop(); > > BTF_SET8_START(key_sig_kfunc_set) > BTF_ID_FLAGS(func, bpf_lookup_user_key, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE) > BTF_ID_FLAGS(func, bpf_lookup_system_key, KF_ACQUIRE | KF_RET_NULL) > BTF_ID_FLAGS(func, bpf_key_put, KF_RELEASE) > +#ifdef CONFIG_SYSTEM_DATA_VERIFICATION > +BTF_ID_FLAGS(func, bpf_verify_pkcs7_signature, KF_SLEEPABLE) > +#endif > BTF_SET8_END(key_sig_kfunc_set) > > static const struct btf_kfunc_id_set bpf_key_sig_kfunc_set = { > -- > 2.25.1 >