Am 04.05.20 um 15:34 schrieb Vladislav Kurz:
> Hello,
>
> I'm not sure If I should post to @bugs.x2go.org or x2go-dev mailing list.
Since you opened a bug report, use <1...@bugs.x2go.org>, that way, all
the right things (TM) will happen automagically.
> 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.
And that's your design flaw that you need to fix.
You really need to separate the logic from the data, so the users can't
access it.
You could, for example, try using stored procedures in a database, and
use Libreoffice or a Web browser as the GUI front end for the database
access.
Or you could try using Libreoffice in headless mode, by querying
parameters from the users in a script, properly sanitizing them
(whitelist the allowed input characters, instead of blacklisting
potentially troublesome ones), then passing them on to be inserted in a
template of your spreadsheet, and automatically print the result to a
PDF. That way, the users won't be in direct contact with your precious
formulas, but only with a script you wrote (which would then call
libreoffice under a user id that has permission to access the
spreadsheet), and with a PDF viewer.
If the users have access to Libreoffice, and to your spreadsheet, they
*will* be able to come up with a way to copy your file. And if it is
formula by formula using a QR code or OCR.
For example, Libreoffice Basic - the Macro language used by Libreoffice
that any user can write macros in - allows raw file I/O.
So it would be possible to read your spreadsheet file byte-by-byte
(bypassing any Libreoffice-internal protections it may have), encode it
in a QR code (current Libreoffice even has its own QR encoder built in),
then scan that code on the client, and save the result as a file.
And once it is stored on the attacker's machine, they can brute-force
their way into whatever protection you tried to apply, until they see
your formulas.
There is NO WAY of making it safe if you don't separate formulas and
data from each other. X2Go won't help you. Switching to a different
remote access solution won't help you. Switching operating systems
won't help you. Your problem is not X2Go, but how mighty and versatile
Libreoffice is.
You're trying to mitigate a severe security/privacy flaw in your basic
design with kludgy workarounds, instead of fixing it properly. This is
hopeless and won't end well.
-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
___
x2go-dev mailing list
x2go-dev@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-dev
