An opinion about Linux security

[Casey Schaufler]

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
>