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: Bug#1465: Bug#1465: Allow running with restricted shell (rbash), or limit applications that can be run.
Reply-To: uli42@gmx.de, 1465@bugs.x2go.org
Resent-From: Ulrich Sibiller <ulrich.sibiller@gmail.com>
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 14:40:02 +0000
Resent-Message-ID: <handler.1465.B1465.15886030439712@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: <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> <2807081.Gr0nKVqjWH@hex>
Received: via spool by 1465-submit@bugs.x2go.org id=B1465.15886030439712
          (code B ref 1465); Mon, 04 May 2020 14:40:02 +0000
Received: (at 1465) by bugs.x2go.org; 4 May 2020 14:37:23 +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=-0.7 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLYTO,
	FREEMAIL_REPLYTO_END_DIGIT,SPF_HELO_NONE,URIBL_BLOCKED autolearn=no
	autolearn_force=no version=3.4.2
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 79DFA5DAC1
	for <1465@bugs.x2go.org>; Mon,  4 May 2020 16:37:20 +0200 (CEST)
Received: by mail-yb1-xb2b.google.com with SMTP id v9so3176736ybq.13
        for <1465@bugs.x2go.org>; Mon, 04 May 2020 07:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:reply-to:from:date:message-id
         :subject:to;
        bh=Bh2ANDvKiPwHKwRsgB3+yqLt1D1+liN6M6lzlAWIn8k=;
        b=kE70EzdUFA7kUjV9qcOR3+r/Z/9+6LIidBab79Mp+CPb1eeVwEOWEOweNvbDUmfxzm
         o7287FMBAi8JtjYvSTHKu0HVVYbhBVpkfQ7FFiREJBzik6PgetG0ulCpCu3KFpBaT5RY
         H80QPj4zEiBKFSxrfQBHxK4eIK+kM7jVplSW+cHFHs6tmK6mJZKW0x3QVPXVii8ruDjt
         FsIELwRdMas3bzTtefeXBeHbZMKbPa5vzoB6Gyw/MxyvhKbxkhvqF6a9gHG7uSRk5ghk
         844vpC7JS3vfhdI3LY3NKdiIPbEF9yEjR2gDWvRvDwdFjocR38wec8/xzOsJS00A9xPn
         ozFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
         :from:date:message-id:subject:to;
        bh=Bh2ANDvKiPwHKwRsgB3+yqLt1D1+liN6M6lzlAWIn8k=;
        b=XwzJpeNPd6yqp43RCJsBXVm8R5kjK8IBmdZXK6OCsJ2pQ2Xsj82c6BK5RbWctEuZjE
         KRMDthVI6MOJ4XvZuqgS3rLe6WO7sSZn5F/Paawrzgnfckmjrjh/uEAMur4L1KXRvfcF
         viUL3wlu4Z/5KV69HXY1kctwhBt4Ix+9U9THtaUEmBw+I50nXya2bbOTh0yVE5KgwTd0
         QGo5mXKo92h11txpZLa1kvyX8b9sqdEWb0sYdkXUXrBtmoGT1T9UqHMIEOawXL6Eumjv
         IaEKAZaJVPEsWWVOO2JjWbhcqnbPRw+8yQxyD0Sqn/DzH0xYTl3tnM04paDLSSbE7jqK
         jfQw==
X-Gm-Message-State: AGi0Pual9pChFwZMwU9r4ea3ZhBDsG9qAD4Ihn0yq1s36YxqYPtmJRy6
	dHVCeYE0va1zMd7NRd5f0kb5C15hwnz/cTYTi04=
X-Google-Smtp-Source: APiQypJnurMipWzXKj/jWkkMXp4fLIPgEvLrtuN9efI2P2N/fRYZJFmKA56sd/fex7aYZ1jYO8qDyrsDLLxIRoj1Vpc=
X-Received: by 2002:a05:6902:513:: with SMTP id x19mr5820597ybs.505.1588603039110;
 Mon, 04 May 2020 07:37:19 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <556ee27c-521d-be03-5a43-08843247b4fb@baur-itcs.de>
From: Ulrich Sibiller <ulrich.sibiller@gmail.com>
Date: Mon, 4 May 2020 16:36:53 +0200
Message-ID: <CANVnVYK8A97S=LswgoH63qkJrx_L+--9JweUTXDXMDBJpbquZg@mail.gmail.com>
To: Stefan Baur <X2Go-ML-1@baur-itcs.de>, 1465@bugs.x2go.org
Content-Type: text/plain; charset="UTF-8"

On Mon, May 4, 2020 at 2:35 PM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
> 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.

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

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

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.

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

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

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.

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

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

> Making false promises is something we should leave to the Microsoft
> Windows world, I'd say. ;)

;-)

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

I have done some research. The reason is that before the scripts used
/bin/sh which is unspecific and might point to other shells. As the
scripts seem to use one or the other bashism this is problematic.

Uli

Send a report that this bug log contains spam.