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 #43 received at 1465@bugs.x2go.org (full text, mbox, reply):

Received: (at 1465) by bugs.x2go.org; 4 May 2020 15:01:16 +0000
From X2Go-ML-1@baur-itcs.de  Mon May  4 17:01:13 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_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.74])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 44C6C5DAD5
	for <1465@bugs.x2go.org>; Mon,  4 May 2020 17:01:13 +0200 (CEST)
Received: from [192.168.0.15] ([78.43.58.112]) by mrelayeu.kundenserver.de
 (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id
 1N8GAQ-1j10sC3f1c-014GLc for <1465@bugs.x2go.org>; Mon, 04 May 2020 17:01:12
 +0200
Subject: Re: [X2Go-Dev] Bug#1465: 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>
 <1902964.pRvSqubr2C@hex> <73e4e27f-a592-5730-2781-f0f80403bdd7@baur-itcs.de>
 <2807081.Gr0nKVqjWH@hex>
 <CANVnVYKUiCR3T9BeYBvNR5ZO7vt7FuXiH=m0J=Z0FSaepu5+Zg@mail.gmail.com>
 <556ee27c-521d-be03-5a43-08843247b4fb@baur-itcs.de>
 <CANVnVYK8A97S=LswgoH63qkJrx_L+--9JweUTXDXMDBJpbquZg@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: <3d0ec19b-9273-4db0-2363-6ff18a4ebc00@baur-itcs.de>
Date: Mon, 4 May 2020 17:01:10 +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: <CANVnVYK8A97S=LswgoH63qkJrx_L+--9JweUTXDXMDBJpbquZg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:k+XiOceQYiwhIwuHOhn1cIteZUXl7LbvNEkVE7H4DklnRHx2J9J
 ndDT35ql19jwky7o4+w8gfv9hIp63EAU0AvsyGy3emKl0wNPB32/wvABtgNt+Nlfz3peAEF
 alMgvF1SfnG3ZEyypFjSC3Fku9gNbijPifYub1YC0dVxHbIJRauvE1NEWL+ZDOmzA5WAY0W
 nD60c3dASnMUz+3X1IGFA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:IYZXGGD6L5o=:m25SCc9083AWbj4qfiHjS4
 ltPfe7LuUSzsfgKuuYxn+i3C3+qqic9NVVguVPJYXXcxtr0wq6U/HkP4QVqzo+ujms7yd8JlW
 FfSCZ2tqSNYacQ1RSBCbQIIbzzHTw5cgWZvObKH16ct18A4nDMWYmJw6g/Y/I7gzPEvvcRIBT
 PSGxOJaO+Iwh+AtviP97ev4vF52qlljmMQVh8588y+0zrjqqCxF0GqES01x6L+PVVSABML6SV
 ImvdNT3er4l18gF0pXih6tWL48nAEA54sFxoxdb6Mhto5QbHzCtrpTZgSMW3onKwjyPNlthOk
 RiULWPEdb4A/8vmPPfSJC2F8EAKmHK+F70BhzkC8pQSAFqj82/hK33EvUAEawSLMlDo0fDBVN
 NBmqHck3xMRbe/L33RnuvCl1XYA2faXLU9oyo0Cn4BHKl2eLSBqqH+bp1jk8criv7oNUOWDif
 plk3hbr+o57X833IFNDBWjbWlenZmfaX0q7Rei3HxiLAksaup+wz1WfoQFwxtioQJT0iQOZq1
 EcYX11rJQtl0b5pRqF2cIEgi6ef1jYKX9nMnj1jKh9MnY47mYBjilMVF87uSt8pKeq5jkTZwS
 poREJvh8DGNZwqSBzRNH6YPtyJnogPHygk0bpZIZzTBIO2SKadMPCJ5AYaRTpjPBOeggD7mLp
 338yPQsB1RaTMfl+x9kwSIJmpUJZPSBZcORP2u0snGIR6KwQoYLWsUURuPUDZ/YZmnb5f5dv+
 4321gVhtDPUFj4pg8ihHGNwdyeARnz7mmHqJgJn1PxXavdMdavkkU3NlePlanp/dudrDVeTp0
 vz7vxG7ZBVyUJ2rLnuonnvyZXVEruyHoIZVs98CvyFGrchlTMsQwxRhX8kgyqfGOmqASUQQ
Am 04.05.20 um 16:36 schrieb Ulrich Sibiller:

> Well, there a things a user requires for the app to run but must now
> get into his hands. Think about a special plugin that does some
> calculation. Or think about a license file that he requires for his
> application to start. Believe me, license-wise you'll find the oddest
> conditions where chmod'ing them away is not an option (we had one
> license software that requires the user to have WRITE access to the
> license file...).

That's third-party stupidity.  Here, however, the issue is with their
very own "product" design.

[...]

> Well, depending on the app this might be possible - or not.
> 
>>> - 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".
> 
> Well, I have not seen "execute" yet, but I have seen "open in file
> manager" and the like. This could be covered with SELinux.

Messy, messy, messy.


>> 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.
> 
> Like in every other situation you are not safe if there are bugs in
> the software. So this is - with the exception of the x2go code itself
> - negligible here.

Not so fast.  This is code that is usually not part of the application
itself, but part of a framework like Qt.  You're importing their bugs.


[...]

> Yes, that risk is always there. Putting your data at a network
> attached machines brings them to risk. You as the user decide if you
> are ready to take the risk or not.

The situation here is a bit different: The *user* totally doesn't mind
if the intellectual property is available like that.  The owner,
however, does ...

>>> 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.
> 
> Well, there's no interactive use here, it is just the session setup. I
> have written such scripts. It is doable.

Then there's an update to the X2Go package that introduces a subtle
change, and boom, your script fails.  Users start to complain and you
are in a hurry to find out what the cause is.  Chances are that in your
panic, you don't think of the wrapper as the probable culprit.

It's a royal pain in the ass.  I've been there.  Which is why my
statement stands:

>> 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.
> 
> Well, as long as you know what your application can do and what not it
> should be handable.

And here's the next catch: They intend to use Libreoffice as their
single published application.  Which allows the user to write their own
macros in Libreoffice Basic.  Which allows them to read binary files and
do things with them.  Like convert them to a bunch of QR codes and
display them.  So to do the things that need to be done, they (the
owners) are depending on an executable which the user can do so much
more with than they want it to do.  And there's no way to limit that,
other than to refrain from using Libreoffice as a front-end.

-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: Thu Aug 13 12:39:18 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.