X2Go Bug report logs - #1465
Allow running with restricted shell (rbash), or limit applications that can be run.

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#1465: [X2Go-Dev] Bug#1465: Allow running with restricted shell (rbash), or limit applications that can be run.
Reply-To: Stefan Baur <X2Go-ML-1@baur-itcs.de>, 1465@bugs.x2go.org
Resent-From: Stefan Baur <X2Go-ML-1@baur-itcs.de>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Mon, 04 May 2020 11:15:01 +0000
Resent-Message-ID: <handler.1465.B1465.158859063714716@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 1465
X-X2Go-PR-Package: x2goserver
X-X2Go-PR-Keywords: 
References: <2807081.Gr0nKVqjWH@hex> <b0f7f18d-b027-712a-9fec-5b91773d13c0@baur-itcs.de> <1902964.pRvSqubr2C@hex> <2807081.Gr0nKVqjWH@hex>
Received: via spool by 1465-submit@bugs.x2go.org id=B1465.158859063714716
          (code B ref 1465); Mon, 04 May 2020 11:15:01 +0000
Received: (at 1465) by bugs.x2go.org; 4 May 2020 11:10:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,RCVD_IN_MSPIKE_H4,
	RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=ham autolearn_force=no
	version=3.4.2
Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 05DA45DAC1
	for <1465@bugs.x2go.org>; Mon,  4 May 2020 13:10:33 +0200 (CEST)
Received: from [192.168.0.15] ([78.43.58.112]) by mrelayeu.kundenserver.de
 (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id
 1N6srB-1j5BLC2R2d-018JYM for <1465@bugs.x2go.org>; Mon, 04 May 2020 13:10:33
 +0200
To: 1465@bugs.x2go.org
From: Stefan Baur <X2Go-ML-1@baur-itcs.de>
Autocrypt: addr=X2Go-ML-1@baur-itcs.de; prefer-encrypt=mutual; keydata=
 xsBNBFLfOiwBCACzIiDVwWVRvuMzgSAvXRFRaPaZOSB8s84PG1oGLfmqhwzF44vj1Xv4tcKD
 mvu0TsLTksOkvop8WwGYeeU8lDaxEG1zyN8SOu1WU/FPEKw2jITRox8yIrSkUsMkWYuxdjv/
 9XcAh9qaPsHP7E1jD6/wVZuYZkuX6W41Nxt06VsvDGCfrbQh4ya7w1IiSnoQeIHNNQVN9f3j
 xcHLj5S5YriSCThtbFCdr3AJXfF5iMolu8kLgAXM0bH1C7PxAjM/pQjWmdMVN/Y+uXXzcMO8
 8aQ0f0q3QeGWxCAP2xwBapUfP6LHDRPp/tV7P7ji8wKlabrSGdv0M9Qd9pn/YCYQE0ZdABEB
 AAHNJlN0ZWZhbiBCYXVyIDxwb3N0bWFzdGVyQHN0ZWZhbmJhdXIuZGU+wsCCBBMBAgAsAhsj
 BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4ACGQEFAlwtWmgFCRK0IbcACgkQbt30GM2+URkj
 nwgAixhVoMxijCsh9jxxCUYBj7lC5HYhJmlAB+bZOfl1XI8xqMLw8YGECfu0VSe++FlaOAuc
 gArofqu79E2+wKxPaqW2lC94eKR1+kgkDOJyqckYj2Xmyi+vDfrOWjbyawIwiq5FUW2CB6zv
 nkTr68ZQ43mAVC1zz2tpAikn2Af4/OdHwUBzSAOpUt4rDbXDe93WW34XuyG2RDma6kE1Cr0u
 ilqvzKOz5SYp5ASmCyaA0wCzs7fjTy2KuMlOCSFRzwPJpzddr8rS9ZiTLdia/BZvShBEjOq4
 MZHWYv+RGK5RB4eDzw0KbPszXRJBUdXiZIcI0jqbC57Ht64ok3lXquXp987ATQRS3zosAQgA
 4KPXmGU1XE8CTRJ/4m/f8MTri3JfEvGJTerWwC2hBuXHGWrSBmmRNAdJHzNTvq5IoR9tQ6Cb
 Nrqxf6alr/v34Vr2bUg0s+jlK9TWOkVLAFoz6zytm/2BrRBIZ5So6Ymfc6efwsScsHOI++wi
 pzqELkpluqtXysb13RsBVLxBdp5TZCVPjCc9pLWjudfjEagQt2oJgtO2WndasrKvoZYkfRi6
 oSCK9B84YjNJoRF00LdK3n7K3SBvj4UPSl+ygzLVaD+3ZdIlbhX+bfn/Vp/10xdJ+/U8Fr7l
 7umrBKr17D8eO3mRYMGY9w1qc+pfNGOR76GIbPWj2tPVaBD9nmUaowARAQABwsBlBBgBAgAP
 AhsMBQJcLVqtBQkStCH9AAoJEG7d9BjNvlEZInkIAIcchwZxurIpwJJR8qMMXD+RSvj7mY55
 VIXOKUX0uAUTEoJTzFcqbdGkzcJB9y0NlUo9dv4chPT21M61y0bjJjhaDUshCLa1+YyFSSWp
 GBOKrLIsWusqC9zVwgf7TtjVmXt23jZwoDWjXoMlg9eQONMi5Z4u+lDOyPKD+lGJAcjJkQsI
 zL9hha3vuhmUclxgdALTJWzQBp+Y7u9QDub4uqf/TyuDpYASiP0winBRfTug+XjP5YZjU//P
 07H9WhiUCsHp6L9j3QzvrovVy2zz0j7JhyhW3e957vHz2skkSVv3QGtHMswcgK3XaQ9YdgWO
 ELHmBhevaIcJIxDvTBl3pYQ=
Message-ID: <73e4e27f-a592-5730-2781-f0f80403bdd7@baur-itcs.de>
Date: Mon, 4 May 2020 13:10:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1902964.pRvSqubr2C@hex>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:nltBuw4dUjjVXPvoR93kxk2Xs57b/T/aXp2IMW5MeBIy5fQ5XkG
 1lHJxIoKXF99a9fSQSdjibYTeCQhPRohfcH8VpT8DfgPSyGssc/UYC7HukBX8byolw52UZ5
 Clr9EYxKsrz8Pq3oeaHkZpj669pzr/Z2WmYSKMp1A1zGZQQ+iYHyOPwyeOm9/exN4T/EKLJ
 Uenw7QQgidAkOoZvjZDNQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:TdHqc7WEWcs=:/LoRwIMoapiYIIqlLu4YKp
 k60i3BRoHi75sMP9SrHlocNiK9tGvY4m4c0UyyYTIKibun2NGleK2tEfM7uwVgQRQyN6gA1ep
 aLsifpS67zc7s0yyyzp6p1fD35CqKvQIbkfKYbv7Ikt5nk3eqAH8GJxxKZFGPMCb8uioRh9AU
 UpLD2kLOwbPMBVb9tvqDg9I9wgqDQoZI0cB8pSIuWyi65dbHQFQpbRi6mKq9LfNJIlNTmKg9C
 tFigQR3dGATY1JziEuH2y2ODjgFSuhCImxjTTCOIuiNpBOR08xTPPKjY4XHFdkkInfsEz9cZz
 ckOlGfImv5uPYD0Ikz+R+swJcahSe0CPBrh0owhH3BtQTksGFaGg9QbIf8lOjmTWdwrVgBKDL
 QqaZyTPt3L/6CKEsvrUoCUcVW2qzFnTIj2Q0In/RgzAZ7mDt0G4sJUl9J1Gb9Ckc72NBroUge
 ageI7Gbg5js+qG16zJg2ly82Zal6xrWe+hWgoBahLcskL6B4Ye4uUIPMcAkcIzERgp8Ub3NhO
 E0OVOJ6DixMJgjvY+fiBWZIvfhcL+ZWnMkfYc/7t9NuFkPncJdf2kcbflVO8XulUuBlW0DnRJ
 cGk2q83eD9uXdm0CBm6arznTi4LkP2CwhF1owbMzrGIwg+VLxru0RcABvzprqeM53H8eCMVsR
 TvMSGRqO16qnTvRUyORcLZr02rPtbpjvHfsSR9Rrt5LZujA9vqa5En1muj0ir4JK/ae9C7DVg
 cAmBy2qTMGdnWzaD0eKhpGqred1Q3LRpPctb+CnFucwB1LrPRfd+rP/H0lmgtMNIuqycVfz8W
 2qFFo9oU3S/GP6O2eJveUlPsqBhC7pmNiN7VpkBY1DN3J9/EvYntpAUZMqHfJD2CVWuzhDo

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

Send a report that this bug log contains spam.