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

Full log

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

Received: (at 1465) by bugs.x2go.org; 4 May 2020 13:34:28 +0000
From vladislav.kurz@webstep.net  Mon May  4 15:34:24 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=-2.0 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,URIBL_BLOCKED autolearn=ham
	autolearn_force=no version=3.4.2
Received: from mail.webstep.net (mail.webstep.net [195.201.172.199])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 03C995DAC1
	for <1465@bugs.x2go.org>; Mon,  4 May 2020 15:34:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=webstep.net
	; s=dkim; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:
	Content-Description; bh=aTIe7tgAoVI5+AW+zpYeHLtavV9Z+5aUSfburggi11A=; b=h00JI
	7xKCURi6S0X260umdakp8LNVyWWgHeXcBxDMExl6lhcCs4+Iv07ZeTdrW06Qd6ryYCSlzxM4F0eQ8
	eN+8MA5Wem0NdJ+nTl07OrDzQVF01x6YOQj2kZL1v/OIGQwS8Y/djUiobvrZgNDVKYnMLCeB7dPR5
	MFmd4DXJu1ck=;
Received: from ip-89-102-32-92.net.upcbroadband.cz ([89.102.32.92]:59580 helo=hex.localnet)
	by mail.webstep.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.89)
	(envelope-from <vladislav.kurz@webstep.net>)
	id 1jVbEl-00007j-Hp
	for 1465@bugs.x2go.org; Mon, 04 May 2020 15:34:23 +0200
From: Vladislav Kurz <vladislav.kurz@webstep.net>
To: 1465@bugs.x2go.org
Subject: Re: [X2Go-Dev] Bug#1465: Bug#1465: Bug#1465: Allow running with restricted shell (rbash), or limit applications that can be run.
Date: Mon, 04 May 2020 15:34:22 +0200
Message-ID: <2471789.PIXMQkQJa5@hex>
User-Agent: KMail/5.2.3 (Linux/4.9.0-12-amd64; KDE/5.28.0; x86_64; ; )
In-Reply-To: <556ee27c-521d-be03-5a43-08843247b4fb@baur-itcs.de>
References: <b0f7f18d-b027-712a-9fec-5b91773d13c0@baur-itcs.de> <2807081.Gr0nKVqjWH@hex> <556ee27c-521d-be03-5a43-08843247b4fb@baur-itcs.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm not sure If I should post to @bugs.x2go.org or x2go-dev mailing list.

Dne pondělí 4. května 2020 14:30:26 CEST, Stefan Baur napsal(a):
> 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.

I have to explain it. The protected thing is openoffice sheet with some complex 
formulas. The formulas should be protected from viewing by openoffice somehow 
(that was not my task so I did not really check that in detail). Users fill in 
input data, get the results, and can print them via CUPS to PDF (or paper). We 
do not want them to get the sheet and use it elsewhere. They are allowed to 
make work copies of the sheet within the protected environment, but should not 
be able to get it out.

So openoffice is the only application they are supposed to run.
I do not want them to be able to run shell at all. Ideally, they should be 
kicked away if they log in with plain ssh.

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

I managed to block file transfer in x2go - by uninstalling fuse on server. 
Although it would be nice to have some switch to disable it server side, and 
allow fuse for other uses.

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

The environment is quite limited and all browsers and similar stuff was either 
uninstalled or chmod 750, so that only root or trusted users can run run it.
Especially xterm, so that there is no reasonable way to run shell via x2go.
openoffice is the only x-application installed.

> They could also use professional screengrabbing equipment...

Using camera to make a screenshot is not a problem. The results of the 
calculation are not protected.

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

That was doing the wrapper mentioned in my original post. I don't know what 
commands are sent by the x2go client. But if it would be just one command that 
it could be put into the ssh forced command.

If I would not need x2go for bandwidth reasons, I would just put oocalc in 
forced commands and use ssh -X. That would provide the protection level I'm 
aiming for.

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

I do not want to replace it. Just need to execute the script like:
x2goruncommand ...    (to let it be found in $PATH)
and not 
bash /usr/bin/x2goruncommand ...
That will let me use rbash which is close to what I need.

The question is where is this call written? Can I modify it myself?
I was trying to find it on server side but failed.

Best Regards
Vladislav Kurz

Send a report that this bug log contains spam.