This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:security:start [2011/05/17 14:45] morty [x2goprint] |
wiki:security:start [2014/01/08 10:20] (current) sunweaver [SQLite] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ~~NOTOC~~ | ||
| + | ====== Thoughts on Security ====== | ||
| + | ===== Session Database Backends ===== | ||
| + | ==== PostgreSQL ==== | ||
| - | ====== Database Access ====== | ||
| - | ===== Postgres ===== | ||
| - | < | ||
| - | Security on database Level | ||
| - | ===== SQLite ===== | + | * In X2Go Server versions prior to 4.0.1.12 (or 4.0.0.10 for the Baikal LTS release branch), |
| - | < | + | |
| - | - Change | + | |
| - | | + | |
| - | ====== | + | ==== SQLite |
| + | |||
| + | * In X2Go Server versions prior to 4.0.1.12 (or 4.0.0.10 for the Baikal LTS release branch), there used to be a [[http:// | ||
| + | |||
| + | |||
| + | |||
| + | ====== X2Go client-side Printing | ||
| <note important> | <note important> | ||
| - | - The Cups-server connects the x2go-Server as x2goprint-user using ssh-key auth. | + | |
| - | - x2goprint-user executes sudo to chenge | + | - cups-x2go CUPS backend runs as root |
| - | * This script can currently be exploited. | + | - as root the backend launches x2goprint (without sudo!!!) |
| - | * If someone becomes x2goprint he might become root. | + | - 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: | ||
| + | | ||
| + | - x2goprint-user executes sudo to change | ||
| + | * This script can currently be exploited. | ||
| + | * If someone becomes x2goprint he might become root. | ||
| ===== Possible solution 1 ===== | ===== Possible solution 1 ===== | ||
| * Start a local cups-server for every user | * 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) | * 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 | * 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) | ||
| + | ===== Possible solution 2 ===== | ||
| + | * Write a simple C-Program ' | ||
| + | * The 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 | ||
| ====== Pulseaudio ====== | ====== Pulseaudio ====== | ||
| - | < | + | < |
| * Currently Pulse-Audio authentication using a cookie-file is used. | * Currently Pulse-Audio authentication using a cookie-file is used. | ||
| * No option of encryption, but can be tunneled via SSH. | * No option of encryption, but can be tunneled via SSH. | ||
| - | * When using the TCE the client has only one user. Therefore the following user may get sounds from the previous, suspended user. | + | * When using the TCE the client has only one user. Therefore the following user may get sounds from the previous, suspended user, if not tunneling pulseaudio. |
| + | |||
| + | ===== Solution for privacy ===== | ||
| + | * Start pulse-audio server on the server | ||
| + | * use sink-tunnel to tunnel to the clinet | ||
| + | * Disconnect sink on suspend | ||
| + | * Send sound to null-dev | ||
| + | * This also solves issues if the client get disconnected unexpectedly. | ||
| - | ====== x2goagent ====== | + | Morty: I looked into this recently (End of 2011). Unfortunately, |
| - | < | + | |
| - | * Is it possible | + | |
| + | ====== X2Go Agent ====== | ||
| + | * [[http:// | ||
| + | * Now, only for XDMCP session the listening port 6050+ is opened (otherwise XDMCP queries do fail) | ||
| + | * If people need x2goagent listening on TCP, it can also be re-enabled in ''/ | ||
| + | | ||