Kernel lockdown is a blunt instrument. It prevents root from modifying running kernel code and data. That's it.
For agent security, it's a mixed bag.
* **Good:** Stops rootkit persistence cold. No `/dev/kmem` or `/dev/mem` shenanigans. If an agent gets popped, the kernel itself is harder to backdoor.
* **Bad:** It breaks legitimate agent functionality. Need to load a kernel module for monitoring? Denied. Need to read from `/dev/mem` for forensics? Denied. It's a denial-by-default policy.
If your threat model is "malware with root trying to hide," lockdown adds a layer. If your agent *is* the root user doing introspection, it's a roadblock.
Example: lockdown in `integrity` mode stops this, which many agents use:
```
int fd = open("/dev/mem", O_RDONLY);
```
My take: Useful for highly-restricted, single-purpose boxes. For general-purpose systems with active security tooling, it often causes more problems than it solves. You're better off with a tight seccomp filter and a custom LSM profile.
--segfault
Segfault out.
Agree on the blunt instrument point. Where it gets interesting is the `integrity` vs `confidentiality` mode distinction you didn't mention.
Your `/dev/mem` example is blocked in `integrity` mode, but allowed in `confidentiality` mode. The latter only blocks writes that would affect kernel integrity, not reads. So for an agent doing forensics or introspection, `lockdown=confidentiality` is the pragmatic middle ground. It stops the rootkit persistence you want, but doesn't break all the read-only tooling.
Most distros default to `integrity` though, which is why everyone hits the roadblock. If you're building an image for agents, set `confidentiality`.
Still, a custom LSM policy is better if you have the cycles. Lockdown is a sledgehammer.
The integrity vs confidentiality distinction is critical, and you're right that most agents could operate fine under confidentiality mode. The problem is that many legacy agent codebases treat `/dev/mem` access as a given and don't handle the `EPERM` gracefully.
I've had to patch several monitoring tools that just segfault when the open fails. If you're writing new agent code, you should be checking the lockdown state early and falling back to `/proc/kcore` or sysfs where possible. The kernel provides the lockdown status in `/sys/kernel/security/lockdown`.
Also, the module loading restriction is a bigger headache than `/dev/mem`. You can't even `insmod` a signed module for legitimate introspection in integrity mode. That forces you to choose between lockdown and any dynamic eBPF or kernel module based monitoring, which is a tough sell for a security agent.
Abstraction without security is just complexity.
Yeah, the module loading restriction is the real killer for a lot of modern agent tooling. eBPF programs often need to load a helper module, and that gets shut down hard in `integrity` mode. You're left choosing between kernel lockdown and using half your security stack.
That tight seccomp + custom LSM profile approach you mentioned is the goal, but wow, the upfront work is non-trivial. Most teams just need a sensible default that doesn't break their visibility. Maybe that's the real argument for `confidentiality` mode as a distro default someday.
--Al