[X2Go-Commits] [[X2Go Wiki]] page changed: doc:howto:tce

wiki-admin at x2go.org wiki-admin at x2go.org
Thu Jan 10 10:57:53 CET 2019


A page in your DokuWiki was added or changed. Here are the details:

Date        : 2019/01/10 09:57
Browser     : Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.9.4
IP-Address  : 149.172.203.221
Hostname    : HSI-KBW-149-172-203-221.hsi13.kabel-badenwuerttemberg.de
Old Revision: https://wiki.x2go.org/doku.php/doc:howto:tce?rev=1547113184
New Revision: https://wiki.x2go.org/doku.php/doc:howto:tce
Edit Summary: [List of open ToDos/FIXMEs for this page] code to put the keystick.key file into the image is already there
User        : stefanbaur

@@ -1144,9 +1144,9 @@
  /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
  cat /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/serial</code> allows to determine the serial number of a USB device. Those SHOULD be unique, but sadly, they aren't (and sometimes, they are missing entirely). Therefore, a USB serial number can't be used for authentication, but it could be
used for "weak" identification - so it could be used to set a default user name or a default session, or to download a particular sessions file.
  Authentification and "hard" identification could be implemented using OpenPGP cards, ''scdaemon'' and a script based on ''/usr/share/doc/scdaemon/examples/scd-event''. For Status ''NOCARD'', suspend the session (kill x2goclient or send a signal that means "suspend", if available, or maybe sighup nxproxy), for status ''USABLE'', run ''gpg --card-status 2>&1 | awk '$1=="Serial" && $2=="number" {print $4}''' to determine the card's serial number, then act based on that (pull new sessions file or set default user, for example, and restart x2goclient).
  
- FIXME Automount script currently expects a LUKS password in ''/etc/keys/keystick.key'' when it believes it has found an encrypted partition on USB media. This is a problem in general, as it should be trivial to sniff out this password using a rogue client. If we want to support this feature,
though, we should add code to the build script that lets the user place a password file in the image, and sets proper restrictive permissions (this would have to happen right before the ''lb build'' call). Adding a boot parameter instead of hardcoding it would allow for dynamic password files (by specifying an URI that points to a CGI script, for example - you could output a different password depending on the source IP range, thus locking media to a particular department, if your departments have different IP ranges), but on the other hand, would make it even easier to sniff out the password. It would only really make sense for Netboot installations, and also not for a MiniDesktop in any way, because you have to block the user from accessing the TCE's local environment/files. And you also have to make sure that people cannot boot rogue clients.  This means a DHCP setup that is locked to known MAC addresses, and physically blocking access to the ThinClient and its network wiring -
because the MAC is displayed during boot, and thus trivial to clone.
+ FIXME Automount script currently expects a LUKS password in ''/etc/keys/keystick.key'' when it believes it has found an encrypted partition on USB media. This is a problem in general, as it should be trivial to sniff out this password using a rogue client. Such a password file would have to be saved as ''./patch/includes.chroot/etc/keys/keystick.key'' (with the proper restrictive permissions) before starting the build. Adding a boot parameter instead of hardcoding it would allow for dynamic password files (by specifying an URI that points to a CGI script, for example - you could output a different password depending on the source IP range, thus locking media to a particular department, if your departments have different IP ranges), but on the other hand, would make it even easier to sniff out the password. It would only really make sense for Netboot installations, and also not for a MiniDesktop in any way, because
you have to block the user from accessing the TCE's local environment/files. And you also have to make sure that people cannot boot rogue clients.  This means a DHCP setup that is locked to known MAC addresses, and physically blocking access to the ThinClient and its network wiring - because the MAC is displayed during boot, and thus trivial to clone.
  
  FIXME ''x2gocdmanager'' is currently not part of the image, but should become part of it. While optical media are on their way out, they still exist and thus we should support them. However, the script is hardcoded for X2Go-TCE-NFS and needs to be adapted to work with both TCEs.
  
  FIXME ''pinentry-x2go'' and ''x2gosmartcardrules'' probably need further investigation to make smartcard authentication work.


-- 
This mail was generated by DokuWiki at
https://wiki.x2go.org/



More information about the x2go-commits mailing list