linux-kernel - Re: [RFC 08/11] 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] [day] [month] [year] [list]

Message-ID: <CAADnVQJ1CRvTXBU771KaYzrx-vRaWF+k164DcFOqOsCxmuL+ig@mail.gmail.com>
Date: Wed, 17 Dec 2025 17:22:31 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jonathan Corbet <corbet@....net>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Mickaël Salaün <mic@...ikod.net>, 
	Günther Noack <gnoack@...gle.com>, 
	"Dr. David Alan Gilbert" <linux@...blig.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, David Howells <dhowells@...hat.com>, 
	LSM List <linux-security-module@...r.kernel.org>, 
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	bpf <bpf@...r.kernel.org>
Subject: Re: [RFC 08/11] security: Hornet LSM

On Wed, Dec 10, 2025 at 6:14 PM Blaise Boscaccy
<bboscaccy@...ux.microsoft.com> wrote:
> +++ b/security/hornet/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config SECURITY_HORNET
> +       bool "Hornet support"
> +       depends on SECURITY
> +       default n

So you're disallowing this new LSM to be a module?
That doesn't smell good.

> +static int hornet_verify_hashes(struct hornet_maps *maps,
> +                               struct hornet_parse_context *ctx)
> +{
> +       int map_fd;
> +       u32 i;
> +       struct bpf_map *map;
> +       int err = 0;
> +       unsigned char hash[SHA256_DIGEST_SIZE];
> +
> +       for (i = 0; i < ctx->hash_count; i++) {
> +               if (ctx->skips[i])
> +                       continue;
> +
> +               err = copy_from_bpfptr_offset(&map_fd, maps->fd_array,
> +                                             ctx->indexes[i] * sizeof(map_fd),
> +                                             sizeof(map_fd));

As was pointed out several times earlier this is an obvious TOCTOU bug.
An attacker can change this map_fd between LSM checks and later verifier use.
All the "security" checks further are useless.

> +               if (err < 0)
> +                       return LSM_INT_VERDICT_BADSIG;
> +
> +               CLASS(fd, f)(map_fd);
> +               if (fd_empty(f))
> +                       return LSM_INT_VERDICT_BADSIG;
> +               if (unlikely(fd_file(f)->f_op != &bpf_map_fops))

Ohh. So this is why this LSM has to be built-in.
bpf_map_fops is bpf internal detail. It's not going to be exported.
You cannot open code __bpf_map_get() and get away with it.

> +                       return LSM_INT_VERDICT_BADSIG;
> +
> +               if (!map->frozen)
> +                       return LSM_INT_VERDICT_BADSIG;
> +
> +               map = fd_file(f)->private_data;
> +               map->ops->map_get_hash(map, SHA256_DIGEST_SIZE, hash);

This too. It's absolutely not ok for LSM to mess with bpf internal state.

The whole LSM is one awful hack.
The diff stat doesn't touch anything in the kernel/bpf/
yet you're messing with bpf internals.

Clearly, you guys want to merge this garbage through LSM tree.
Make sure to keep my Nack when you send it during the merge window.