User Tools

Site Tools


wiki:security:start

This is an old revision of the document!


Thoughts on Security

Session Database Backends

PostgreSQL

No known exploits

SQLite

No known exploits

X2Go client-side Printing

Might be exploited if someone becomes x2goprint-user

  1. X2goServer == CUPS Server, latest implementation (as of 20110909):
    1. cups-x2go CUPS backend runs as root
    2. as root the backend launches x2goprint (without sudo!!!)
    3. 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.
  2. X2goServer != CUPS Server:
    1. The Cups-server connects the x2go-Server as x2goprint-user using ssh-key auth.
    2. 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
  • + 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 '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
  • + Can be easily adopted
  • - x2goprint must be installed by the client
  • - s-bit → Needs security checks

Pulseaudio

No known exploits / Privacy issues

  • Currently Pulse-Audio authentication using a cookie-file is used.
  • 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, 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.

Morty: I looked into this recently (End of 2011). Unfortunately, due to the buffering done on the server, this might start to “swing” (playback getting faster and slower again and again).

X2Go Agent

wiki/security/start.1387314710.txt.gz · Last modified: 2013/12/17 21:11 by sunweaver