(no title)
aumerle | 1 year ago
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.
mitchellh|1 year ago
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.
gigatexal|1 year ago
aumerle|1 year ago
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?