You must log in or register to comment.
- 5 days
The only application I see for this is AI-based bullshit, which makes this needlessly complicated.
Static scripts don’t get “confused”, and they certainly don’t get manipulated on a properly secured system. Why would you need an extra layer of security past the layers that already exist, when just properly securing the existing layers should be more than enough?
5 daysThe only application I see for this is AI-based bullshit, which makes this needlessly complicated.
Static scripts don’t get “confused”, and they certainly don’t get manipulated on a properly secured system. Why would you need an extra layer of security past the layers that already exist, when just properly securing the existing layers should be more than enough?
It’s not a AI application. AI is just the loudest fire right now, not the whole point. Its a new authority substrate for the whole system, intent-bound and enforced at the kernel level. A static script doesn’t get “confused,” sure. But scripts can still be wrong, overbroad or run in the wrong context or inherit more authority than they need or sit behind a supply-chain change you didn’t expect. Same with normal userland processes.
KERNHELM isn’t “because scripts have feelings.” It’s because ambient authority is just a bad default.
Existing layers are useful. I’m not saying throw them out. This is a different authority shape. Instead of “is this user, process, category usually allowed,” the question becomes “was this specific privileged effect actually admitted through the trusted path and carry the users intent”
Agents make the issue obvious because they can be steered in plain language. But the substrate is broader than AI. Anything untrusted reaching for privileged effects should have to prove authority at the effect boundary. Be it malware, an active attacker, overbroad script, compromised process or an AI agent.
- 5 days
You’re just describing a lesser SELinux or AppArmor implementation at that point if that’s how you intend to use.
What’s the differentiation?
Yeah, I get why it reads that way at first, but I don’t think SELinux/AppArmor and KERNHELM are trying to answer the same question. SELinux/AppArmor are good broad confinement tools. They can say “this process/profile/domain is generally allowed to do X.”
KERNHELM is aimed at the standing authority problem underneath that. The issue is not just “can this process do this kind of thing.” The issue is “why does this process get to keep that authority sitting around at all?”
So instead of: “this program is allowed to delete files in this area”
KERNHELM wants: “this exact delete, against this exact target, was admitted through the trusted path for this user intent right now.” Then that authority burns/expires/revokes. It is not reusable standing permission. That’s why I don’t see it as lesser SELinux. SELinux/AppArmor can still define the broad walls. KERNHELM is more like a checkpoint at the gate: show the permit for this specific action right now, or it doesn’t happen. The thing that made this class of idea hard historically was latency. If every action has to stop and ask a model, remote service, or heavy policy engine what the user meant, it’s dead. KERNHELM’s move is to resolve intent before the hot path, convert it into narrow mechanical authority, and make the actual gate check cheap.
- CameronDev@programming.devEnglish5 days
Its AI slop, do you really expect them to know what they are talking about?
Fair question.
Code exists, but this repo is not the source drop yet. It’s the paper, claims, threat model, measurements. I held the implementation back because of a provisional patent side of this, but I’m probably going to publish a cleaned proof repo and the demo.
So yeah, if your bar is “show me the code,” this post does not clear that yet. Thats a fair hit.
