| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAP01T77y+7tGAUKXzNtchPLKFmWm6PAvxCnwm1Lqqjusj1JbRQ@mail.gmail.com>
Date: Wed, 7 Sep 2022 15:55:54 +0200
From: Kumar Kartikeya Dwivedi <memxor@...il.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: joannelkoong@...il.com, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
mykolal@...com, dhowells@...hat.com, jarkko@...nel.org,
rostedt@...dmis.org, mingo@...hat.com, paul@...l-moore.com,
jmorris@...ei.org, serge@...lyn.com, shuah@...nel.org,
bpf@...r.kernel.org, keyrings@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
deso@...teo.net, Roberto Sassu <roberto.sassu@...wei.com>
Subject: Re: [PATCH v16 07/12] bpf: Add bpf_verify_pkcs7_signature() kfunc
On Wed, 7 Sept 2022 at 14:20, Roberto Sassu
<roberto.sassu@...weicloud.com> wrote:
>
> On Wed, 2022-09-07 at 04:28 +0200, Kumar Kartikeya Dwivedi wrote:
> > On Tue, 6 Sept 2022 at 10:08, Roberto Sassu
> > <roberto.sassu@...weicloud.com> wrote:
> > > On Tue, 2022-09-06 at 04:57 +0200, Kumar Kartikeya Dwivedi wrote:
> > > > On Mon, 5 Sept 2022 at 16:35, Roberto Sassu
> > > > <roberto.sassu@...weicloud.com> wrote:
> > > > > From: Roberto Sassu <roberto.sassu@...wei.com>
> > > > >
> > > > > 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 <roberto.sassu@...wei.com>
> > > > > Acked-by: KP Singh <kpsingh@...nel.org>
> > > > > ---
> > > > > 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 7a7023704ac2..8e2c026b0a58 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_p
> > > > > tr),
> > > >
> > > > MIssing check for data_ptr->data == NULL before making this call?
> > > > Same
> > > > for sig_ptr.
> > >
> > > Patch 3 requires the dynptrs to be initialized. Isn't enough?
> > >
> >
> > No, it seems even initialized dynptr can be NULL at runtime. Look at
> > both ringbuf_submit_dynptr and ringbuf_discard_dynptr.
> > The verifier won't know after ringbuf_reserve_dynptr whether it set
> > it
> > to NULL or some valid pointer.
> >
> > dynptr_init is basically that stack slot is now STACK_DYNPTR, it says
> > nothing more about the dynptr.
> >
> > As far as testing this goes, you can pass invalid parameters to
> > ringbuf_reserve_dynptr to have it set to NULL, then make sure your
> > helper returns an error at runtime for it.
>
> I see, thanks.
>
> I did a quick test. Pass 1 as flags argument to bpf_dynptr_from_mem()
> (not supported), and see how bpf_verify_pkcs7_signature() handles it.
>
> Everything seems good, the ASN1 parser called by pkcs7_parse_message()
> correctly handles zero length.
>
> So, I will add just this test, right?
>
Yeah, if it handles it correctly, just adding a test to make sure it
stays that way in the future would be fine.
Powered by blists - more mailing lists