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.
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.
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.
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.
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.
It's not even slightly tricky, just use self pipe. I have no idea why the maintainer of make rejected it. He says select has different signatures, but select is in POSIX, so unless he is porting to a non POSIX platform, it's irrelevant and even if he is, I doubt it is that hard to write a wrapper to abstract the non POSIX compatible implementation of select. Then he complains about needing to do CLOEXEC on the self pipe. This is trivial (one line) on Linux using pipe2 and about 5 lines of code on other platforms. Given that he says make does not use threads its also perfectly robust without pipe2.
Opting for a harder algorithm just to avoid a few lines of compatibility shims seems like very much the wrong tradeoff.
Lots of modern terminals support ws_xpixel and ws_ypixel. Hell even the venerable xterm supports it. It is used primarily for displaying raster graphics in modern terminals, see for example: https://sw.kovidgoyal.net/kitty/graphics-protocol/#getting-t...
My point was not that the terminals don't report ws_xpixel and ws_ypixel, but rather that none support the application setting the resolution using tcsetwinsize() with the terminal subsequently changing its video mode / resizing itself to the requested size.
Ah yes, in that case there no terminals that implement it indeed. Though there are a few that implement changing window size via escape code, though in units of cells not pixels. Generally speaking I dont see how applications can use tcsetwinsize() robustly, given that the size in pixels of a cell is determined by font properties and applications runing in the terminal have no knowledge of these, therefore cannot set both the pixel and cell sizes at the same time.
Correct, that was one of the concerns. Note that tcsetwinsize() is mainly provided so that the pty master (i.e. the terminal emulator) can set the window size to be seen by the slave (i.e. the application running in the emulated terminal). The other direction is not explicitly banned though.
FYI, there are a few terminals that can set the window size in pixels (with `CSI 4 t`). And it's also worth mentioning that there were already terminal emulators back in the 1980s that supported in-band resize notifications (lookup `VTEEWR` - Enable Window Event Reports).
Furthermore, remote control in kitty has capability based security where you can lock down the protocol to allow individual actions with arbitrary granularity:
And that's just what he did until someone showed up to do the grunt work of porting to Python 3, at which point he co-operated with that person and helped make the port happen, just as he said he would. I suggest a more facts based narrative in the future.
Ah, you are back with your "the kitty protocol doesn't support my pet feature that nothing else supports, aka left and right distinct modifier states" so it must be bad. I was wondering when you would show up again.
This article is a perfect illustration of why Webapps will never be as good as native ones. Webapps are always "untrusted" code so they are arbitrarily and artificially restricted from accessing resources on your local machine.
Untrusted by default is a feature. No user would be able to protect themselves, unless perhaps they are a highly trained security expert always on alert, which is not a thing.
This is not the exciting early days of the interwebz where script kiddies run amok and it’s mostly for the geeks anymore, it’s where government-affiliated gangs are launching ransomware attacks on critical infrastructure in order to finance nuclear programs. Accessing arbitrary resources on your local machine is how that happens.
Web apps, given a modern browser, naturally have stricter sandboxing, but native apps are treated as untrusted on any modern OS, too. If I launch anything new, the dialog will have me confirm before it accesses anything other than its isolated app data directory.
I dont run a single native application across five operating systems that requires a popup nag to access the clipboard or that is unable to put any data other than text, html and PNG on the clipboard.
Every mobile OS from Apple would show a popup if an app tried to access clipboard without your explicit pasting. Obviously, if you tapped “paste” then popup would be unnecessary since you would be approving your own action, not app’s action.
It is somewhat crazy that macOS doesn’t do that yet.
But the comment I replied to was talking in general terms. Yes, for some APIs native apps are for now more trusted than Web apps, depending on the OS, but the trend is that they are becoming less and less trusted.
Nope, native applications are not ever going to get the ridiculous level of sandboxing demonstrated by the restrictions on accessing the clipboard in the article. Nor are they ever going to be prevented from accessing the file system as web applications are.
Now, the OP has to remember, df -h -x tmpfs instead of df -h. The proper solution for this is to not have commands that are both meant for interactive and script usage. Then the defaults for their output can be changed over time to suit the evolving landscape. Or if you do want a single command for both have a --script flag that makes its output suitable for usage in scripts.
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.