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: <CAADnVQJ5VaXVN=L+0ygEWJkMtPZnqAVEoeFiLBvikntX0zD49w@mail.gmail.com>
Date: Fri, 11 Apr 2025 17:57:49 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Matteo Croce <technoboy85@...il.com>
Cc: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>, 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

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ