Hi All -
There is a post on the new site re printing security (see below). Does anyone have experience with Possible Solution 1? We're hoping to get a few more pointers, maybe some extra documentation, some "here's how you avoid these pitfalls". Thanks!
X2goServer == CUPS Server, latest implementation (as of 20110909):
cups-x2go CUPS backend runs as root
as root the backend launches x2goprint (without sudo!!!)
x2goprint script changes owner ship of PDF file and pushes it into SSHFS share towards the X2go client.
using X2go printing locally (X2go server == CUPS server) then security (sudo) is not an issue any more(?)
Nope still is (not a big one, though): Using CUPS the user can easily be faked, allowing to fill someone else's quota or print at their home printer.
X2goServer != CUPS Server:
The Cups-server connects the x2go-Server as x2goprint-user using ssh-key auth.
x2goprint-user executes sudo to change the ownership of the PDF file and pushes it into SSHFS share towards the X2go client.
This script can currently be exploited.
If someone becomes x2goprint he might become root.
Possible solution 1
Start a local cups-server for every user
Server listens on a File-socket owned by the user
Add a PDF-Printer to that server (as the cups-user runs as that user, there should be no issues with file permissions)
Import printers from global server
Possible solution 2
Write a simple C-Program 'x2goprinter' that is run as the user who wants to print unsing the s-Bit
The Program writes stdin to argv[1] in the printing-directory
It also checks whether the user is x2goprint or root
x2goprint must be installed by the client
s-bit → Needs security checks
Hi,
On Di 24 Jan 2012 21:26:54 CET wrote:
Hi All -
There is a post on the new site re printing security (see below).
Does anyone have experience with Possible Solution 1? We're hoping
to get a few more pointers, maybe some extra documentation, some
"here's how you avoid these pitfalls". Thanks!
nothing of the below has been implemented yet. I will comment on some
of the ideas.
X2goServer == CUPS Server, latest implementation (as of 20110909):
[...]
using X2go printing locally (X2go server == CUPS server) then
security (sudo) is not an issue any more(?)Nope still is (not a big one, though): Using CUPS the user can
easily be faked, allowing to fill someone else's quota or print at
their home printer.
Ok, good point.
Possible solution 1
Start a local cups-server for every user
Server listens on a File-socket owned by the user
Add a PDF-Printer to that server (as the cups-user runs as that
user, there should be no issues with file permissions)Import printers from global server
- Secure solution, as no other user is involved
- Every user needs an extra instance (The extra memory usage should
not be too much)
This has been discussed on the mailing list and the consensus was to
stay away from CUPS instances on a user basis. However, if someone
starts on implementing I will be happy to review and support coding.
Possible solution 2
Write a simple C-Program 'x2goprinter' that is run as the user who
wants to print unsing the s-BitThe Program writes stdin to argv[1] in the printing-directory
It also checks whether the user is x2goprint or root
- Can be easily adopted
x2goprint must be installed by the client
s-bit → Needs security checks
I have already spent a couple of hours on a possible setuid/setgid-bit
solution. At the end I came to the conclusion that s-bit approaches do
not work with the current print file transfer workflow. Maybe I was
brain-blocked here, so if someone comes up with a proof of concept I
would love to support a moval away from sudo here.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...