[PATCH v2 security-next 1/4] security: Hornet LSM
Paul Moore
paul at paul-moore.com
Tue Apr 22 02:38:09 UTC 2025
On Mon, Apr 21, 2025 at 7:48 PM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
> On Mon, Apr 21, 2025 at 3:04 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Mon, Apr 21, 2025 at 4:13 PM Alexei Starovoitov
> > <alexei.starovoitov at gmail.com> wrote:
> > > On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy
> > > <bboscaccy at linux.microsoft.com> wrote:
> > > >
> > > > > Hacking into bpf internal objects like maps is not acceptable.
> > > >
> > > > We've heard your concerns about kern_sys_bpf and we agree that the LSM
> > > > should not be calling it. The proposal in this email should meet both of
> > > > our needs
> > > > https://lore.kernel.org/bpf/874iypjl8t.fsf@microsoft.com/
> >
> > ...
> >
> > > Calling bpf_map_get() and
> > > map->ops->map_lookup_elem() from a module is not ok either.
> >
> > A quick look uncovers code living under net/ which calls into these APIs.
>
> and your point is ?
Simply the observation that the APIs you've mentioned are currently
being used by code living under net/; you're free to take from that
whatever you will.
> Again, Nack to hacking into bpf internals from LSM,
> module or kernel subsystem.
I heard you the first time and rest assured I've noted your general
objection regarding use of the BPF API. I'm personally still
interested in seeing a v3 before deciding on next steps as there were
a number of other issues mentioned during the v2 review that need
attention. I would encourage you to continue to participate in future
reviews of Hornet, but of course that is entirely up to you. In the
absence of any additional review feedback, I'll preserve your NACK if
we ever get to a point that your comments are worth mentioning.
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list