An opinion about Linux security

[Stephen Smalley]

On Fri, Dec 12, 2025 at 9:47 AM Timur Chernykh <tim.cherry.co at gmail.com> wrote:
>
> Thanks for the answer!
>
> > eBPF has been accepted because of these restrictions. Without them
> > an eBPF program could very easily reek havoc on the system's behavior.
>
> Unfortunately, these restrictions also make it impossible to use eBPF
> effectively for security. We can certainly discuss the limitations
> themselves if needed, but that’s not the main point I’m trying to make
> here.

There was no shortage of talks about using eBPF for security at LPC this week,
https://lpc.events/event/19/sessions/235/#all

If eBPF can't do what you want today, I suspect it will in the
not-too-distant future.
The best way to make it so would be to try implementing your desired
functionality using it, find the cases where it is currently
insufficient and then take those to LPC or other venues to argue for
enhancements to enable it to do so. Doing so may require re-thinking
how you implement that functionality to fit within the required safety
constraints but that doesn't mean it is impossible.

> > Please propose the interfaces you want. An API definition would be
> > good, and patches even better.
>
> I’m lucky enough to have already built a working prototype, which I
> once offered for review:
>
> https://github.com/Linux-Endpoint-Security-Framework/linux/tree/esf/main/security/esf
> https://github.com/Linux-Endpoint-Security-Framework/linux/tree/esf/main/include/uapi/linux/esf
>
> Less lucky was the reaction I received. Paul Moore was strongly
> opposed, as far as I remember. Dr. Greg once said that heat death of
> the universe is more likely than this approach being accepted into the
> kernel.

Not seeing an actual response from Paul in the archives, but did you
ever actually post patches to the list? Posting a GitHub URL is NOT a
real request for review.


> I don’t want to “poke old wounds”, but the design I proposed was
> largely inspired by Apple’s Endpoint Security Framework (originally
> “mac policies”):
> https://developer.apple.com/documentation/endpointsecurity
>
> In my view, it is an exemplary model. The kernel provides a consistent
> stream of events to userspace, hides the complexity of data collection
> and transport, and ensures fault-tolerance if userspace fails to
> process events quickly enough.
> Audit, for comparison, simply hangs the system if its buffer
> overflows. ESF does not have that problem and even lets userspace
> control the event stream.
>
> > There are numerous cases where LSMs have mitigated attacks. One case:
>
> And there are thousands of cases where LSMs did not. Most companies
> never disclose successful breaches because of NDAs and fear of
> investor backlash. The few disclosures we see typically appear only
> when it’s safe for the company, or when they specifically want to
> appear transparent.
>
> > Your assertion that LSMs don't provide "real" value is not substantiated
> > in the literature.
>
> Which literature do you mean?
> As I mentioned above, public reports about successful attacks are rare.
>
> Maybe I poorly delivered my point. I'll try again.
>
> The strongest protection on Linux today is provided by proprietary
> security vendors. Unfortunately, they often achieve this using
> kernel-module “hacks” rather than LSMs. It’s not because they prefer
> hacks — it’s because Linux doesn’t offer proper APIs to implement the
> required functionality.
>
> > Each of the existing LSMs addresses one or more real world issues. I would
> > hardly call any of the Linux security mechanisms, from mode bits and setuid
> > through SELinux, landlock and EVM, "theoretical".
>
> In practice, most LSM modules are either disabled or misconfigured on
> real servers, and the responsibility falls on AV/EDR vendors. As
> someone who has been building such systems professionally for years, I
> can say with confidence: there is no clean, reliable mechanism
> available today.
> As much as I love Linux, its security and its friendliness toward
> security vendors are its weak side.
>
> In the real world, deploying a modern security product means dealing
> with endless pain: missing kernel headers (sometimes there isn’t even
> Internet access to download them), unstable kernel APIs, lack of BTF,
> constant fights with the eBPF verifier, and all the other limitations
> of eBPF.
>
> To be honest, many developers — and I’m taking the liberty to speak
> broadly here — would simply like to see something similar to Apple’s
> ESF available on Linux.
>
> Best regards,
> Timur Chernykh
>
> On Wed, Dec 10, 2025 at 11:08 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> >
> > On 12/9/2025 4:15 PM, Timur Chernykh wrote:
> > > Hello Linus,
> > >
> > > I’m writing to ask for your opinion. What do you think about Linux’s
> > > current readiness for security-focused commercial products? I’m
> > > particularly interested in several areas.
> > >
> > > First, in today’s 3rd-party (out-of-tree) EDR development — EDR being
> > > the most common commercial class of security products — eBPF has
> > > effectively become the main option. Yet eBPF is extremely restrictive.
> >
> > eBPF has been accepted because of these restrictions. Without them
> > an eBPF program could very easily reek havoc on the system's behavior.
> >
> > > It is not possible to write fully expressive real-time analysis code:
> > > the verifier is overly strict,
> >
> > This is of necessity. It is the only protection against malicious and
> > badly written eBPF programs.
> >
> > > non-deterministic loops are not
> > > allowed,
> >
> > Without this restriction denial of service attacks become trivial.
> >
> > >  and older kernels lack BTF support.
> >
> > Yes. That's true for many kernel features.
> >
> > > These issues create real
> > > limitations.
> > >
> > > Second, the removal of the out-of-tree LSM API in the 4.x kernel
> > > series caused significant problems for many AV/EDR vendors. I was
> > > unable to find an explanation in the mailing lists that convincingly
> > > justified that decision.
> >
> > To the best of my understanding, and I have been working with LSMs
> > and the infrastructure for quite some time, there has never been an
> > out-of-tree LSM API. We have been very clear that the LSM interfaces
> > are fluid. We have also been very clear that supporting out-of-tree
> > security modules is not a requirement. There are members of the
> > community who would prefer that they be completely prohibited.
> >
> >
> > > The next closest mechanism, fanotify, was a genuine improvement.
> > > However, it does not allow an AV/EDR vendor to protect the integrity
> > > of its own product. Is Linux truly expecting modern AV/EDR solutions
> > > to rely on fanotify alone?
> >
> > You will need to provide more detail about why you believe that the
> > integrity of an AV/EDR product cannot be protected.
> >
> > > My main question is: what are the future plans?
> >
> > Security remains a dynamic technology. There are quite a few plans,
> > from a variety of sources, with no shortage of security goals. Trying
> > to keep up with the concern/crisis of the day is more than sufficient
> > to consume the resources committed to Linux security.
> >
> > >  Linux provides very
> > > few APIs for security and dynamic analysis.
> >
> > What APIs do you want? It's possible that some exist that you haven't
> > discovered.
> >
> > >  eBPF is still immature,
> >
> > And it will be for some time. That is, until it is mature.
> >
> > > fanotify is insufficient,
> >
> > Without specifics it is quite difficult to do anything about that.
> > And, as we like to say, patches are welcome.
> >
> > >  and driver workarounds that bypass kernel
> > > restrictions are risky — they introduce both stability and security
> > > problems.
> >
> > Yes. Don't do that.
> >
> > >  At the same time, properly implemented in-tree LSMs are not
> > > inherently dangerous and remain the safer, supported path for
> > > extending security functionality. Without safe, supported interfaces,
> > > however, commercial products struggle to be competitive. At the
> > > moment, macOS with its Endpoint Security Framework is significantly
> > > ahead.
> >
> > Please propose the interfaces you want. An API definition would be
> > good, and patches even better.
> >
> > > Yes, the kernel includes multiple in-tree LSM modules, but in practice
> > > SELinux does not simplify operations — it often complicates them,
> > > despite its long-standing presence. Many of the other LSMs are rarely
> > > used in production. As an EDR developer, I seldom encounter them, and
> > > when I do, they usually provide little practical value. Across
> > > numerous real-world server intrusions, none of these LSM modules have
> > > meaningfully prevented attacks, despite many years of kernel
> > > development.
> >
> > There are numerous cases where LSMs have mitigated attacks. One case:
> >
> > https://mihail-milev.medium.com/mitigating-malware-risks-with-selinux-e37cf1db7c56
> >
> > Your assertion that LSMs don't provide "real" value is not substantiated
> > in the literature.
> >
> > > Perhaps it is time for Linux to focus on more than a theoretical model
> > > of security.
> >
> > Each of the existing LSMs addresses one or more real world issues. I would
> > hardly call any of the Linux security mechanisms, from mode bits and setuid
> > through SELinux, landlock and EVM, "theoretical".
> >
> > > P.S.
> > > Everything above reflects only my personal opinion. I would greatly
> > > appreciate your response and any criticism you may have.
> >
> > We are always ready to improve the security infrastructure of Linux.
> > If it does not meet your needs, help us improve it. The best way to
> > accomplish this is to provide the changes required.
> >
> > > Best regards,
> > > Timur Chernykh
> > >
>