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