5 ms·

Imperfect, incomplete, yet useful measures I take including building with some of Clang's sanitizers and running the program through a bubblewrap wrapper for fi

by Seirdy 5y ago

Imperfect, incomplete, yet useful measures I take including building with some of Clang's sanitizers and running the program through a bubblewrap wrapper for filesystem sandboxing paired with a seccomp filter that allows a limited list of safer syscalls (including some W^X enforcement).

leetrout 5y ago
Is there a blog or webpage that summarizes all of this in one place?
vidarh 5y ago
With the caveat this may be useful to guard against exploitation of bugs, not against a malicious terminal (which can e.g. quietly wait for a user to ssh or su and intercept the password, and then execute code on the background). Not to dissuade people from hardening them as I'm all for that. (I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
- Seirdy 5y ago
  bubblewrap and/or selinux can prevent the terminal from making network connections. but yeah, this is better for bugs.
  - vidarh 5y ago
    You can stop it doing all kinds, but if you do, then it's not usable as a general purpose terminal. That's the problem. A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with. That ability can equally be used for malicious purposes. E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too. There certainly can be situations were a constrained terminal could be useful too, though
    - Seirdy 5y ago
      Not necessarily; it could simply connect to a tmux session.
      - vidarh 5y ago
        In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...

by Seirdy 5y ago

leetrout 5y ago

Is there a blog or webpage that summarizes all of this in one place?

vidarh 5y ago

With the caveat this may be useful to guard against exploitation of bugs, not against a malicious terminal (which can e.g. quietly wait for a user to ssh or su and intercept the password, and then execute code on the background). Not to dissuade people from hardening them as I'm all for that. (I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)

Seirdy 5y ago
bubblewrap and/or selinux can prevent the terminal from making network connections. but yeah, this is better for bugs.
- vidarh 5y ago
  You can stop it doing all kinds, but if you do, then it's not usable as a general purpose terminal. That's the problem. A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with. That ability can equally be used for malicious purposes. E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too. There certainly can be situations were a constrained terminal could be useful too, though
  - Seirdy 5y ago
    Not necessarily; it could simply connect to a tmux session.
    - vidarh 5y ago
      In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...