Hacker News Reader

Comment by aumerle | Hacker News Reader

You proposal does not address this issue since shells would still need full privileges.

This entire class of exploits (query responses with user controlled data leading to shells executing commands) would be removed if shells just moved to using the kitty keyboard protocol with all key events represented as escape codes and implemented a full escape code parser for data received form the terminal. You cannot embed an escape code inside another, or while technically you can, it is trivial to implement a security policy of disallowing these in both terminals and shells. Then barring implementation bugs in the escape code parser (which can easily be shipped as a standalone native code library) you dont have this entire class of issues and the associated one that the bracketed paste hack was created to address.

View on HN

I believe it could. A shell could reduce capability by default for all executed shell scripts (file or inline on the prompt) and require opt in to not do this. Something akin to a umask of sorts. It’d break exceedingly few real scripts. (Hand waving a lot here with the “opt in” mechanism to avoid that being scripted but I have ideas)

Also note my thoughts (very much not even close to being a proposal) are very raw. Inviting this kind of discussion is exactly what I hope to do :)

Reduction of capability in general is not intended to address all class of security issue. For example you’d still want unsafe paste detection (to detect newlines or attempted bracketed paste escapes) on a prompt line.

But I think having a mechanism to eliminate the possibility of entire class of actions without wholesale disabling them in the terminal emulator is a desirable property. Right now a lot of these features are mostly on/off.

So if I am to understand your proposal more concretely it is something like implement an escape code that the shell can use to turn off all other escape codes (presumably with some kind of listing mechanism) and then have the shell do that before launching any third party script/program/function? How would the shell know which escape codes the program it is running needs?

I can, kind of, see the utility of a pledge() type system within a single program, but in a shell, whose whole job is basically running programs it knows nothing about beyond their name? How would that work?

Sorry to be a broken record but I have no “proposal” whatsoever. It’s more of an information sharing and seeking discussion. I don’t know what I want yet except that I think we can do better. The end result could be that it’s all a terrible idea and that’s okay, but hopefully something comes out of it eventually.

Id love to continue this discussion, but I think HN threads probably aren’t the right medium. If you’d like I can email you or we can schedule a call. I’m not trying to seek privacy, I’d be happy for any to be recorded or shared publicly, I just don’t find HN to be a good place if you really want to dive into this!

Of course, I didn't mean to put you in a spot. We can always continue this later once your thoughts have matured. Sadly I have an extremely full schedule so I dont think I have the badwidth to noodle on this at this stage but if and when you have something more concrete please do post it somewhere public and I will try to contribute to the discussion.

Appreciate it! <3

But strangely have a lot of time to post here

And a lot of time to post only about kitty XD

aumerle is Kovid Goyal, the author of kitty.

Thanks for calling this out.

I'll remember his comments as an example of how much pettiness both drives and undermines OSS.

I've discussed with Mitchell a bit in the past on this, but there are a few ways to opt in to this. First, let's imagine there is some escape sequence that tells the terminal to ignore some set of escape sequences.

1. The shell could have a keybind (say, ctrl+enter) which runs the command with (for example) only styling enabled (CSI m sequences).

2. You could write a wrapper around any program to do the same. The shell doesn't need to know anything about the system, but instead you have a wrapper that disables and then reenables said sequences.

3. A program itself can opt in by turning on the feature at launch. This allows CLI / TUI developers to "safeguard" their programs from malicious attacks.

Whatever you all do please continue the fight. I love love love the ergonomics of the terminal. It feels like a super power for me and is crucial to my work flow. If someone told my CTO that terminals are an attack vector they might do something silly and ban them — might sound crazy but management has gone crazier things.

Reply on news.ycombinator.com