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

version graph

Package: x2goserver; Maintainer for x2goserver is X2Go Developers <x2go-dev@lists.x2go.org>; Source for x2goserver is src:x2goserver.

Reported by: Vladislav Kurz <vladislav.kurz@webstep.net>

Date: Wed, 22 Apr 2020 16:25:01 UTC

Severity: wishlist

Found in version 4.1.0.3-0~1708~ubuntu16.04.1

Full log


Message #23 received at 1465@bugs.x2go.org (full text, mbox, reply):

Received: (at 1465) by bugs.x2go.org; 4 May 2020 12:30:32 +0000
From X2Go-ML-1@baur-itcs.de  Mon May  4 14:30:28 2020
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_H2,
	SPF_HELO_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.2
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id F37615DAC1
	for <1465@bugs.x2go.org>; Mon,  4 May 2020 14:30:27 +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
 1MfpGR-1iubjW14pt-00gISq for <1465@bugs.x2go.org>; Mon, 04 May 2020 14:30:27
 +0200
Subject: Re: [X2Go-Dev] Bug#1465: Bug#1465: Allow running with restricted
 shell (rbash), or limit applications that can be run.
To: 1465@bugs.x2go.org
References: <b0f7f18d-b027-712a-9fec-5b91773d13c0@baur-itcs.de>
 <2807081.Gr0nKVqjWH@hex> <1902964.pRvSqubr2C@hex>
 <73e4e27f-a592-5730-2781-f0f80403bdd7@baur-itcs.de>
 <CANVnVYKUiCR3T9BeYBvNR5ZO7vt7FuXiH=m0J=Z0FSaepu5+Zg@mail.gmail.com>
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: <556ee27c-521d-be03-5a43-08843247b4fb@baur-itcs.de>
Date: Mon, 4 May 2020 14:30:26 +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: <CANVnVYKUiCR3T9BeYBvNR5ZO7vt7FuXiH=m0J=Z0FSaepu5+Zg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:sXaj9I1nhbz+LNJNCZwpiaKpFLChErLipdR3Kmzu34j/FUdkWDs
 TKE4K8c+hA/xmlkz4yqXXaJgKt0PqpBpzGf3VYL76rafd3xbEptLmv9ZzEVicX1muIGnGtr
 9LMGF6GOO14g9oPgwlCQcGjM43IG3LoMJHZTr4BCi2/zVg+vcchniiYATx5TvrjOjk4grn3
 nhvPRV7e9QQYsnDN5kClQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mEssxltSPvs=:ichh+hq2TM5QSJta4dFIaF
 o6rYl247mcBivsfDJqG3DYfTrhIrHdbWLJ9p+f4J/IeKPtLtzXewso0NHv9Y96u6f4MuPr+vS
 oWqQPZmC1P3oxhCKrplfcYKYmi6EJmicJNaY3NA5HxbVu4yf/Fss24Uch4LoVElWhz94JIXSl
 6ES4s+xM5onSsMy87NR4EPLgLJS6svIdaAVLTmRcQ1CiSbVwCzWykTylDlFMOYwj2Z5qTAGtu
 NA1wApkbRIRiTfAcsQ1c5w7L1MF/WgY2HRW4JdkW5EfA0RLUh46ewIb8GOHYBs69rXoRLN9Ft
 nfykTHnu5ThaeJWoOruBzFT3olPqLPcjDEVn96Jkrq9Fy69r/AZveuWoKjPWRQ/S/f4AYsqVP
 nXLCPz7oIj7q7KBAy9Way1GOLqce0x5P+c3+1IxXIL4rft4Va+f9WDwvfcHKdFAkJRiUizL5z
 NG6K85Tg+5ccgbGcydjMlgan6AlEOFv9JS845ecIChWaqQ4Wbj8Ub8DiRMMYIG8B/dR56rEPa
 qUqBQo3GRTzNb2JWqmnymsG3ErqUvGNvtUxVlRqRKzVxqHR3nqWQZW2oYxXk0k9HACpsl9zrh
 tQ1yvhyRy8xvslkfDMTkxo4qNgs/2ugZwOJGbsI3VulPfeGpkh7eY9+DcCDBdXMT8+0rtpSMS
 3Ri8KrDs7EjhTUqwgkZGT3lH4Roe2YHpCXS+alLNSYHPY4UfyT+37wLkmyLDUKoITbLkVTPKo
 Z1LvSVLfRvfLqOm+UQWx3cBRO2DP3tpx9DNeVbJ96/nw+DPRE+AKi/RjAQ7UGjp76l4BaRBfN
 YLOagVrpnP9N8VkteBeq22bziXpQWLi1lVBN3EVwW4i6KEtKdjeP13uJOjg3CMzAOYeBaZV
Am 04.05.20 um 14:06 schrieb Ulrich Sibiller:
> On Mon, May 4, 2020 at 1:15 PM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
>> You need to realize the truth: What a user can see (as in "access"),
>> they can copy.
> 
> Well, I basically agree with what you wrote. But the OP was mentioning
> he just wants to provide _one_ single published application.
> 
> Now let us assume some pre-conditions:
> - the application is unable to display the data you want to protect.
> If not, all the ways you mocked up above could be used and the
> approach will not work

And that's the catch: If the application can't display the data - then
why would the user need access to it at all?  chmod/chown it away from
them and you're good to go.  But obviously the data is needed *somehow*,
or else they wouldn't have the problem of wanting to hide it from the user.

If it's raw data vs. processed data (e.g. points of data in a CSV file
vs. a graph generated from it), then (and only then) the solution is simple:
You need an app (a daemon, probably - though it might be done per-call
with passwordless sudo or the suid bit set on that app) that processes
the raw data and runs under another account, and another app that is
able to talk to this app, which can only display the processed data.
That way, you can use file system permissions to "wall off" the raw data
so only the processing app can access that data.


> - the application cannot start other apps like an xterm or a shell on
> user request

And that is particularly hard, as experience shows.  Even a "file
chooser" dialog from a standard GUI toolkit that you use for selecting a
data file will usually offer you a right-click option with "execute".
Navigate to the xterm binary (path traversal via ../../../ and the like
is another problem to keep in mind, even if you're able to hide critical
directories from view) and there's your shell.
One such item that you forget about, and boom - you've been exploited.


> - there's only ssh access
> - the x2go scripts are sane and secure

That's something I wouldn't want to bet my money on without an extensive
audit.  And even then there's the risk that the audit missed to spot
something.


> Then all we'd need was
> - a restricted ssh-key that only allows for the commands that are
> required for the x2go session handling

Which doesn't work out of the box.  You can specify exactly one command.
To be able to use more than one, you need a wrapper script on the host
that is set as forced command, which then parses $SSH_ORIGINAL_COMMAND.
These scripts are notoriously bad to maintain, error-prone, and while
they work with scripted commands (e.g. running an automated rsync job
with varying target directories), they suck hard for interactive use.


> - ensuring the x2go session handling will only start that single
> application and no other user specified command.
> 
> The user then can still configure arbitrary sessions but they will
> either always fail or ignore the user's command and run the one
> application in question. We could also provide a server side setting
> that only allows published application connects.
> 
> It will not work out of the box but I am pretty sure it could be implemented.

To me, it sounds like a horrible kludge that is bound to collapse rather
sooner than later, and it would only offer a false sense of security.
Making false promises is something we should leave to the Microsoft
Windows world, I'd say. ;)


> Also, IIRC Mihai added an explicit bash call into certain commands to
> make it work fur users with a different login shell. And obviously the
> original rbash instructions worked before. So you could also try to
> set that up and do some research where to remove the explicit bash
> calls.

Given that bash is enforced there for a reason, it doesn't sound like a
good idea to replace it with something else.

-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.


X2Go Developers <owner@bugs.x2go.org>. Last modified: Fri Aug 7 01:59:56 2020; Machine Name: ymir.das-netzwerkteam.de

X2Go Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.