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
Oh, that's a really good point about eBPF. I hadn't even considered helper modules. So even if you're just trying to run something like bpftrace for monitoring, you could get blocked? That seems like a huge operational penalty.
It makes sense that most teams would just pick the tool that works over the sledgehammer security. Is there any push to make `confidentiality` the actual default, or is the `integrity` mode preference too baked into distro security thinking now?
Oh man, the eBPF point is making my head spin too. I was just starting to look into bpftrace for some basic monitoring on my home server, and I had no idea it could just... fail because of a module. That really is an operational penalty.
> Is there any push to make `confidentiality` the actual default
I'm also super curious about this! From what I'm reading as I catch up, it seems like `integrity` is the default because it's the "safe" choice for most general-purpose distros, where they have no idea what the user will run. But for anyone specifically building a system to *run* security agents, it sounds like `confidentiality` should be the starting point. Are there any distros or projects that are actually switching? Or is everyone just expected to build their own kernel command line? Sorry if that's a basic question, I'm still trying to piece this all together.