XPost: comp.sys.raspberry-pi, alt.os.linux.mageia   
   From: gtaylor@tnetconsulting.net   
      
   On 12/9/23 12:13, Markus Robert Kessler wrote:   
   > Dammit. I read above article and tested on Mageia and on Raspbian.   
   > Assuming same behaviour on Ubuntu.   
      
   I'm not at all surprised.   
      
   The underlying -- so called -- problem has been well known and   
   understood by many in the Unix community for a long time.   
      
   In short, don't give untrusted people / apps / things access to your X11   
   display server.   
      
   > So, quite slowly, I suspect more and more that Debian based distros are   
   > not enabling su - / x-app right out of the box, by intention.   
      
   Not enabling `su -` in and of itself tends to come from a different   
   place, mostly one of trying to avoid the existence of the super user;   
   UID / GID of zero.   
      
   avoiding / denying super user (root) is a completely different discussion.   
      
   That being said, not going out of their way to enable cross user X11   
   access is probably somewhat intentional.  Or at least insofar as   
   choosing to have people enable it if they want it, ostensibly assuming   
   that they understand the risks involved with doing so.   
      
   > I already handled with caution to log into online banking during M$ teams   
   > meetings, because for audio in-/output they need access to the desktop,   
   > and hence they could take screenshots from other windows like online   
   > banking app.   
      
   If an X11 client application can access an X11 display server, then said   
   X11 client application can take a screen shot of said X11 display   
   server.  They can also read keys / mouse or worse inject keys / move the   
   mouse.   
      
   > So, it looks like, the only proper approach is to completely log off from   
   > the X11 session instead of su - / x-app, or open a second X11- / desktop   
   > session.   
      
   No, not really.  The key thing to remember is that *any* *access* /to/   
   /an/ /X11/ /display/ /server/ is tantamount to *FULL* *ACCESS* /to/ /an/   
   /X11/ /display/ /server/.   
      
   With that in mind, it is critical to clarify what is the X11 display   
   server in each context.   
      
   Things like Xvnc and Xnest (whatever their actual names are today)   
   provide a /new/ /and/ /separate/ /X11/ /display/ /server/.  As such an   
   application that has access to X11 display server :10 doesn't inherently   
   have access to X11 display server :0.   
      
   The use of separate X11 display servers is critical.   
      
   With this in mind, you should be able to relatively safely run a virtual   
   X11 display server via Xvnc / Xnest / etc. and have less trusted   
   applications use it as their DISPLAY.  Then use the proper viewer to   
   cause things on the virtual X11 display server to appear on your   
   physical X11 display server.   
      
   Things like Xvnc have the VNC protocol in separate / isolate the :0.0   
   X11 display server and the :10.0 X11 display server.  This isolation   
   barrier makes it MUCH more difficult for things to pass through.  What's   
   more is that Xvnc, et al. usually have much more control over what can   
   and can't pass through the protocol divide.   
      
   I remember reading about people running multiple X11 display servers   
   akin to virtual terminals (Control) Alt-F#.  Wherein things on different   
   X11 display servers, which happen to use the same display hardware at   
   different times, have separate data and are much more isolated from each   
   other.   
      
      
      
   --   
   Grant. . . .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)