linux-kernel - Re: [PATCH v2 security-next 1/4] security: Hornet LSM

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87plhhjwqy.fsf@microsoft.com>
Date: Sat, 12 Apr 2025 07:11:01 -0700
From: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>, Matteo Croce
 <technoboy85@...il.com>
Cc: Jonathan Corbet <corbet@....net>, David Howells <dhowells@...hat.com>,
 Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller"
 <davem@...emloft.net>, Paul Moore <paul@...l-moore.com>, James Morris
 <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Masahiro Yamada
 <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas
 Schier <nicolas@...sle.eu>, Shuah Khan <shuah@...nel.org>, Mickaël Salaün
 <mic@...ikod.net>, Günther Noack <gnoack@...gle.com>, Nick
 Desaulniers
 <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>,
 Justin Stitt <justinstitt@...gle.com>, Jarkko Sakkinen
 <jarkko@...nel.org>, Jan Stancek <jstancek@...hat.com>, Neal Gompa
 <neal@...pa.dev>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, keyrings@...r.kernel.org, Linux
 Crypto Mailing List <linux-crypto@...r.kernel.org>, LSM List
 <linux-security-module@...r.kernel.org>, Linux Kbuild mailing list
 <linux-kbuild@...r.kernel.org>, "open list:KERNEL SELFTEST FRAMEWORK"
 <linux-kselftest@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
 clang-built-linux <llvm@...ts.linux.dev>, nkapron@...gle.com, Matteo Croce
 <teknoraver@...a.com>, Roberto Sassu <roberto.sassu@...wei.com>, Cong Wang
 <xiyou.wangcong@...il.com>
Subject: Re: [PATCH v2 security-next 1/4] security: Hornet LSM

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Fri, Apr 11, 2025 at 5:30 PM Matteo Croce <technoboy85@...il.com> wrote:
>>
>> Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov
>> <alexei.starovoitov@...il.com> ha scritto:
>>
>> Similar to what I proposed here?
>>
>> https://lore.kernel.org/bpf/20211203191844.69709-2-mcroce@linux.microsoft.com/
> ...
>> @@ -1346,6 +1346,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; /* instruction's signature */
>> + __u32 sig_len; /* signature size */
>
> Well, yeah, two fields are obvious.
> But not like that link from 2021.
> KP proposed them a year later in 2022 on top of lskel
> which was much closer to be acceptable.
> We need to think it through and complete the work,
> since there are various ways to do it.
> For example, lskel has a map and a prog.
> A signature in a prog may cover both, but
> not necessary it's a good design.
> A signature for the map plus a signature for the prog
> that is tied to a map might be a better option.
> At map creation time the contents can be checked,
> the map is frozen, and then the verifier can proceed
> with prog's signature checking.
> lskel doesn't support all the bpf feature yet, so we need
> to make sure that the signature verification process
> is extensible when lskel gains new features.
>
> Attaching was also brought up at lsfmm.
> Without checking the attach point the whole thing is quite
> questionable from security pov.

That statement is quite questionable. Yes, IIRC you brought that up. And
again, runtime policy enforcement has nothing to do with proving code
provenance. They are completely independent concerns.

That would be akin to saying that having locks on a door is questionable
without having surveillance cameras installed.