[X2Go-Dev] Bug#1465: Bug#1465: Allow running with restricted shell (rbash), or limit applications that can be run.

[Stefan Baur]

Am 04.05.20 um 10:12 schrieb Vladislav Kurz:

[...]

> What we need is to block users from copying files from the x2go server. So we 
> have to deny /bin/cat or /bin/dd to be invoked via ssh. But x2go will not 
> connect without /bin/cat being executable.

Sorry to disappoint you, but ...

in the early days of computing, there was a software copyright
infringement case in a German court of law, and the judge, being new to
computers, after having listened to all the expert witnesses, summed up
his impression as "A computer is a machine to copy ones and zeroes."

And that's the truth.

There are so many ways that files/data can be copied from a machine a
user has access to that you *will* fail blocking it.

(Of course, this isn't fully valid for files the user has no access to
at all - but what a user can read, they can copy.)

This is by all means anything but a comprehensive list, just a few ideas
most people don't think of at all:

- X2GoClient has file sharing built in.  It's easy to hide the feature,
  but users that know that it's there may still be able to use it.
- Users can create their own executables.  Or bash scripts.
  Or Perl Scripts.  Or, or, or.  (Yes, mounting all directories they
  have write access to -noexec does help.  A tiny little bit.)
- Bash itself has a netcat-like TCP and UDP client module built in. See
  "man bash", search for "/dev/tcp/host/port" and "/dev/udp/host/port".
- You could probably write a QR encoder in the macro language belonging
  to LibreOffice or whatever word processor is in use on the system.
  Then the user points their smartphone at the screen, scans the code,
  decodes the content.
- Web browsers allow upload forms.  And JavaScript, which could also be
  used for a QR encoder.
- Command line web browsers like lynx, elinks, even wget and curl can be
  used to upload files.
- Anything that works as a hex editor/hex viewer can be used to display
  even binary content on the screen, which can then be screenshotted
  either digitally or using a smartphone camera/webcam pointed at the
  screen.  These days, OCR does a pretty good job at reassembling such
  data.
- They could also use professional screengrabbing equipment, either as
  software or hardware looped into the VGA/HDMI cable.  (Oh, and even if
  you were to use the copy-protection features of HDMI - forget about
  it.  There are cheap Chinese HDMI converters that don't give a shit
  about that copy protection and will stream the unencrypted signal to
  whatever recording device you hook up to them.)
- They could attempt to use morse code, or even create a serial
  connection, making the keyboard CAPS LOCK/NUM LOCK/SCROLL LOCK LEDs
  blink and either use software on the client to decode it, or have
  light sensors on their keyboard LEDs to interpret the signals. (one
  LED would be CLOCK, the other DATA; for the return path, the third LED
  would be CLOCK, and e.g. a simulated space or shift or CTRL key push
  would be DATA).  Commands to make the LEDs blink are available both
  for the console and for X11.

etc. etc. etc.

Even if you find solutions for the points I listed above, there will be
way more.  And all it takes it one way you didn't think of, but your
user did think of, and you're fucked.


>> Anything X2Go would try place on top of that would be bound to fail, as
>> it can easily bypassed by a user running X2Go with a custom
>> configuration, or SSHing into the machine with ssh -X, thus bypassing
>> X2Go entirely.
> 
> Would it be possible to make some sort of wrapper that could be set as user's 
> shell that will allow only establishing x2go session? Something like setting 
> x2goruncommand as users shell?  Something like scponly. Then one could focus 
> on blocking only x-applications like xterm, etc.

No.  You would not be the first to try, but you will also not be the
last to fail if you try.

You need to realize the truth: What a user can see (as in "access"),
they can copy.

So, if you're looking to block access to certain executables: Yes, that
may work, with varying levels of success.  If you're looking to block
users from copying data they are supposed to have read access to: Forget
about it.

Even if you managed to block every transfer other than to the screen
itself, you'd basically have to strap VR goggles to their head, verify
their identity via retina scan, and immediately cut off the display
stream if they attempt to take the goggles off. ;-)
And even then you run the risk that someone hacks the VR goggle hardware
in a way that you can't detect and taps recording equipment into the
stream.  Or that one of your users has eidetic memory and can just write
down/draw everything they saw after the session ends.

-Stefan

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243