3 ms·

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f https://gist.github.com/cielave

by bmacho 19d ago

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f... On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.

rwmj 19d ago
That doesn't change that programs doing this can be shady (or very useful).
- wolfi1 19d ago
  but sandboxing would be quite useless
  - shevy-java 19d ago
    How so? If you can break out of a sandbox then by definition it is not a sandbox. There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS (https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-distribution-i-heard.html https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.
    - wolfi1 19d ago
      X itself is the problem here, not the process attached to
    - imtringued 19d ago
      You need to sandbox X11 which requires giving up X11 capabilities just like Wayland did.
wolfi1 19d ago
could xhost(1) help here?
- roryirvine 19d ago
  Not really - it's not sufficiently fine-grained and, besides, you need it to connect to X to display anything. There were various attempts to improve this situation in the early 2010s, typically using Xnest or Xephyr in conjunction with other sandboxing techniques. I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention. The fact is that the X model was never designed with these threats in mind.
  - fsflover 18d ago
    > I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention. Not sure what you are talking about. Qubes offers reliable protection with decent performance, unless you work with graphics. See also: https://news.ycombinator.com/item?id=49678250 https://news.ycombinator.com/item?id=49678250
- cookiengineer 19d ago
  I think the only possibility that comes to mind is creating an ebpf module that sandboxes all filesystem calls and trampolines all ld_open calls. But then you would have to provide massive amounts of patched/"safe" variants of all kinds of shared libraries which is unfeasible. But I mean in the xorg use case it would be possible to just provide your own library that fakes the expected returns and sends fake data to the sandboxed applications. I did a similar thing with barrier (though using LD_PRELOAD, see [1]) on my debian system to force a different behavior. Source: Am kind of experimenting with ebpf a lot for that use case. C ABIs and SO files are a mess though. A real messy mess. [1] https://github.com/cookiengineer/barrier-disable-dpms https://github.com/cookiengineer/barrier-disable-dpms

by bmacho 19d ago

rwmj 19d ago

That doesn't change that programs doing this can be shady (or very useful).

wolfi1 19d ago
but sandboxing would be quite useless
- shevy-java 19d ago
  How so? If you can break out of a sandbox then by definition it is not a sandbox. There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS (https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-distribution-i-heard.html https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.
  - wolfi1 19d ago
    X itself is the problem here, not the process attached to
  - imtringued 19d ago
    You need to sandbox X11 which requires giving up X11 capabilities just like Wayland did.

wolfi1 19d ago

could xhost(1) help here?

roryirvine 19d ago
Not really - it's not sufficiently fine-grained and, besides, you need it to connect to X to display anything. There were various attempts to improve this situation in the early 2010s, typically using Xnest or Xephyr in conjunction with other sandboxing techniques. I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention. The fact is that the X model was never designed with these threats in mind.
- fsflover 18d ago
  > I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention. Not sure what you are talking about. Qubes offers reliable protection with decent performance, unless you work with graphics. See also: https://news.ycombinator.com/item?id=49678250 https://news.ycombinator.com/item?id=49678250
cookiengineer 19d ago
I think the only possibility that comes to mind is creating an ebpf module that sandboxes all filesystem calls and trampolines all ld_open calls. But then you would have to provide massive amounts of patched/"safe" variants of all kinds of shared libraries which is unfeasible. But I mean in the xorg use case it would be possible to just provide your own library that fakes the expected returns and sends fake data to the sandboxed applications. I did a similar thing with barrier (though using LD_PRELOAD, see [1]) on my debian system to force a different behavior. Source: Am kind of experimenting with ebpf a lot for that use case. C ABIs and SO files are a mess though. A real messy mess. [1] https://github.com/cookiengineer/barrier-disable-dpms https://github.com/cookiengineer/barrier-disable-dpms