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/
_______________________________________________
x2go-commits mailing list
[email protected]
https://lists.x2go.org/listinfo/x2go-commits