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