Omarchy has changed its Kitty configuration after a security issue was identified with allow_remote_control yes.
That setting allows Kitty’s remote-control protocol to accept commands from terminal output, meaning untrusted output could potentially execute commands as the current user. Kitty itself defaults this setting to no; the exposure came from Omarchy explicitly enabling it so other parts of the desktop could query the active terminal’s working directory.
The change disables remote control by default and migrates existing explicit yes settings to no. Users affected by the migration need to fully close and reopen Kitty, as existing processes remain exposed until they exit.
There is a small trade-off: Omarchy can no longer reliably determine the active Kitty tab/pane’s working directory via its socket, so new terminal or Files launches may occasionally fall back to the home directory.
The associated migration tests reportedly pass, although no live Kitty test was run in the test environment.
You must log in or register to comment.
This reminds me of the Docker issue they fixed in Omarchy recently. Basically you could get root through the docker socket, because the default user groups included the docker group.
Omarchy can no longer reliably determine the active Kitty tab/pane’s working directory via its socket
Imagine this as the reason to allow remote access without questions. I watched an interview and he is proud to fix those issues (there were a few more security issues of this stupidity class) and thinks this is totally normal. And over time after fix after fix, Omarchy will become secure. He admits Omarchy is unsecure at this time. Edit: I should probably link to the interview in question: Invidious or YouTube
The users are just beta testers, risking getting hacked. I could not trust this project. Even if all issues are fixed, who says no new security issues will make into the project? Omarchy is worse than Ubuntu and Manjaro combined.
So opinionated.
Sloooopinionated
Clearly the results of either being high on slop or a literal mass exploiter
In Kitty’s defense, the docs mention the risks involved with full remote control, and there several ways to control the scope of permitted actions.
It’s tricky though. I’d like my coding agent to be able to control the terminal, but I’ve found it harder to sandbox kitty than, say, a multiplexer like tmux/zellij. Herdr is a bit less obvious.
It has its uses, I think the issue mainly stems from having it on by default rather than asking than explaining the risks on first use and asking the user what they’d like to do.
That does not allow remote code execution. An attacker still needs a vector like an SSH session to be able to control kitty. And at that point, if they already have a shell session, they don’t need kitty to do damage.
edit: giving access to other programs is not remote execution, but obviously not a good default.
It actually also allows other programs to execute code through Kitty, example if you cat a file that has escapes in it. It would allow Kitty to execute that code when you never intended it… But like why does kitty even have that as a feature? But they’ve since updated the config to be set to socket only instead of yes
Would you call that a Kitty cat? 🐈
yes, I get that and it’s a bad default, but not RCE like the post says
Having the feature seems pretty in line with the general Linux philosophy. Let the user decide, even if that means they screw it up. Same reason you can muck up an install by just running updates on storage that doesn’t have enough room to do so. It’s up to the end user to understand, verify, and choose to execute.
