SysKnife 0.3.0 is live in the registry: typed Linux actions instead of a shell string

[vladimirrott]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

What I built. SysKnife is a stdio MCP server for Linux system administration that deliberately has no exec tool. GuardFall got past the safety guard in 10 of 11 open-source coding agents, because a guard reads text while bash rewrites text before running it, so the design premise here is that the server never emits a shell string at all.

Five tools: sysknife_plan, sysknife_execute, sysknife_history, sysknife_doctor, sysknife_audit_verify. Plan returns typed steps drawn from a catalogue of 189 actions, each with a risk level and a transaction id, then stops.

SysKnife MCP flow (https://raw.githubusercontent.com/lacs-project/sysknife/main/assets/demo/mcp-flow.gif)

How I built it. Rust workspace, six crates, with the privilege split as the organising principle. The MCP server runs unprivileged and every mutation crosses a sysknife:sysknife 0750 unix socket to a daemon that owns the sudoers, polkit and helper policy. Caller role comes from SO_PEERCRED, the kernel's answer about who connected, rather than a field in the request body. Execution requires a single-use, TTL-bounded receipt that only sysknife approve , typed by a human in a terminal, can mint; sysknife_execute rejects missing, expired, mismatched and replayed receipts, and the server cannot mint them itself. Every executed action is Ed25519-signed into a forward hash chain that a third party verifies with only the exported public key.

Challenges.

Signing on a moving constant. The chain version was a single CURRENT constant, so bumping it silently re-encoded historical rows while unit tests stayed green, because they signed and verified under the same constant. The fix was frozen per-version literals plus golden on-disk vectors with a negative twin, so a flipped nibble reports Broken.

SO_PEERCRED does not fail cleanly across namespaces. It substitutes the overflow uid (65534) and pid 0 instead of erroring, so a container peer looked like a real account. 0.3.0 records none:unattributed in that case, because an honest "I could not tell" beats signing a uid the kernel never vouched for. The other two forms are uid:1000 and token:vsock.

Directory sandboxes cannot validate this class of server. A sandbox that builds a container and boots it lists all five tools, because tools/list is static metadata, but it cannot call the ones that need a privileged daemon. I had documented the opposite at one point and had to correct it.

What's next. Ubuntu 24.04 is validated at 65/65 stories on a live VM, 20.04 and later supported; Fedora Atomic 41+ is eligible but not yet VM-validated, and that run is the next milestone.

Relevant Links

• GitHub repository: https://github.com/lacs-project/sysknife
• Registry entry: io.github.lacs-project/sysknife (0.3.0, isLatest)
• Documentation: https://lacs-project.github.io/sysknife/
• Audit chain design: https://github.com/lacs-project/sysknife/blob/main/docs/the-audit-chain.md
• Security model: https://github.com/lacs-project/sysknife/blob/main/SECURITY.md
• Install: npx sysknife-setup