linux-kernel - RE: [PATCH v6 4/5] bpf: Add bpf_verify_pkcs7

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2be48d62b0c141799f0c54cbe63f6dc3@huawei.com>
Date:   Fri, 8 Jul 2022 12:12:25 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     "dhowells@...hat.com" <dhowells@...hat.com>
CC:     "ast@...nel.org" <ast@...nel.org>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "songliubraving@...com" <songliubraving@...com>,
        "kafai@...com" <kafai@...com>, "yhs@...com" <yhs@...com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        KP Singh <kpsingh@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>
Subject: RE: [PATCH v6 4/5] bpf: Add bpf_verify_pkcs7_signature() helper

> From: Roberto Sassu [mailto:roberto.sassu@...wei.com]
> Sent: Thursday, July 7, 2022 1:01 PM
> > From: KP Singh [mailto:kpsingh@...nel.org]
> > Sent: Thursday, July 7, 2022 1:49 AM
> > On Wed, Jul 6, 2022 at 6:04 PM Daniel Borkmann <daniel@...earbox.net>
> > wrote:

[...]

> > > nit: when both trusted_keyring_serial and trusted_keyring_id are passed to
> the
> > > helper, then this should be rejected as invalid argument? (Kind of feels a bit
> > > like we're cramming two things in one helper.. KP, thoughts? :))
> >
> > EINVAL when both are passed seems reasonable. The signature (pun?) of the
> > does seem to get bloated, but I am not sure if it's worth adding two
> > helpers here.
> 
> Ok for EINVAL. Should I change the trusted_keyring_id type to signed,
> and use -1 when it should not be specified?

I still have the impression that a helper for lookup_user_key() is the
preferred solution, despite the access control concern.

David, may ask if this is the correct way to use the key subsystem
API when permission check is deferred? key_permission() is currently
not defined outside the key subsystem.

The first three functions will be exposed by the kernel to eBPF programs
and can be called at any time. bpf_<key_helper> is a generic helper
dealing with a key.

BPF_CALL_2(bpf_lookup_user_key, u32, serial, unsigned long, flags)
{
...
        key_ref = lookup_user_key(serial, flags, KEY_DEFER_PERM_CHECK);
...
        return (unsigned long)key_ref_to_ptr(key_ref);
}

BPF_CALL_X(bpf_<key_helper>, struct key, *key, ...)
{
        ret = key_read_state(key);
...
        ret = key_validate(key);
...
        ret = key_permission(key_ref, <key helper-specific permission>);
...
}

BPF_CALL_1(bpf_key_put, struct key *, key)
{
        key_put(key);
        return 0;
}

An eBPF program would do for example:

SEC("lsm.s/bpf")
int BPF_PROG(bpf, int cmd, union bpf_attr *attr, unsigned int size)
{
        struct key *key;
...
        key = bpf_lookup_user_key(serial, flags);
...
        ret = bpf_key_helper(key, ...);
...
        key_put(key);
}

Thanks

Roberto