Am Montag, den 30.07.2007, 10:02 -0600 schrieb Roy Souther: > Francis, your post got me thinking. > > I am a big fan of SSH PKI. If a login manager could be made to require > and id_dsa key, would that make the session more secure?
The point of a trusted system is that it can be verified to be trusted right from the boot stage. That is why Win NT 4 had the Ctrl+Alt+Del requirement when logging on - that keystroke could not be intercepted by any screensaver mimicking a login screen (or similar), so you could be absolutely sure that it either brings the task manager (if someone is logged in) or the security dialog that you can use to login or resume a locked session. In LTSP circumstances, if you manage to setup a second boot server that loads a Linux image to the client which looks pretty much like the real thing and connects to the real server, but has some kind of key- and screen logging modules compiled into the Xserver component (or whatever), the user could not see the difference. The trouble is that this is not even too difficult, people who know their way around LTSP probably could setup something like that in less than a day, with no visible difference to the user. Security can only reasonable be had if you verify the boot server is the real server, and this has to be done by means of cryptography. > Maybe the open source etherboot project could be made to require > server identity before booting. We had a patch (actually I was the one to bring that patch into Etherboot) that would download a file and check an embedded crypto checksum against a public key that had to be hardcoded into the Etherboot ROM. That was back in NBI days, and NBIs usually had several dozens of free bytes in the header. The last 32 bytes of those unused (iirc) had to contain a binary value, which was derived by MD5-ing the rest of the NBI and then encrypting the result with a private key. So Etherboot could also produce that md5 checksum and verify that the image could only have been built by someone with the correct private key. The patch came under the name "SAFEBOOTMODE", if you are interested to find more info about it. It had never been expanded to support generic images or other storage modes for the public key storage. There are reasons for the lack of further development: - Etherboot was planned to get a generic interface to read the small configuration eeproms on most network cards, which possibly have room for a pub key storage - The NBI-centric way was meant to be replaced by a separate download. As GPXE (the Etherboot successor) learns to directly boot linux kernels, one might implement an extra download of a checksum file, for example named like the kernel plus an extra file extension or the like - Well, and I am lazy. Best excuse ever, ain't it? > One way an attack like this could happen would be in a large > unsupervised area. A person brings a laptop that will server the > terminal an OS that has been modified with a key logger and let them > login to the X session on the real server. The user would be unaware > of anything, because it would still be their normal desktop session. Right. > One way to stop this would be to have the server host terminal OS > with a special program that uses encryption to verify the terminal and > the programs on the terminal, then reject any X session connections > from system that have not been verified. And here comes the trouble: If everyone can download the linux image, everyone could read the scriptworks. We are talking open source, so security by obscurity is out of the game. Let us be glad about this: Such S-B-O solutions always risk breaking any time that someone gains access to code that he should never see. It is bound to happen. See google about ATMs/cash machines and their management console, if you want a good half-sour laugh about SBOs and real life. You will have to secure the clients such that any of "your" clients will only boot a proper image. This does not save you from physical security: Like someone replacing a client with a machine that boots from CF instead of network and simulates a login screen as written above. Once physical security of the terminals is screwed, so are you. Let us assume you cannot protect the network (CAT5 plugs and such), which will be the status at most LTSP installations. You should at least be able to make sure that the thin clients are not tampered with: If security is your concern, they should be bolted or locked to the tables anyway, and any screws to open them should be sealed. > Would it be possible for a program to detect the presents of a new > unauthorized DHCP server? Yep, several ways to do that. You could either monitor incoming DHCPDISOVER packets and log their occurence against incoming DHCPREQUESTs (which will work if you are behind a switch, because you will see ALL DHCPDISCOVERs, as those are network broadcasts). This would of course trigger an alarm if someone reboots one of the terminals between DISCOVER and REQUEST, and those two might be several seconds apart. Otherwise you could use a "mirror" port on your switch that hands out ALL traffic on the network without filtering out packets that are not meant for your Ethernet device. In that case, logging all DHCPOFFER packets would reveal any bastard playing tricks on your network. > I am not actively developing for the LTSP project so I cannot say how > hard these things would be or if they would even help much, but I do > believe that security is an issue that needs constant work. Security is a way, not a destination (Zen for beginners) > I do not think MS was considering security by requiring a full OS > locally installed. Given the low ability to protect an MS system from > viruses and spyware I suspect that installing a key logger on to > dozens of MS terminals would be much faster then a few Linux > terminals. Extra license fees is most likely the only reason MS > requires a full OS on the terminal. I would consider the MS attempts of selling secure products as that: Attempts. Just that it was not the sales people to fail, obviously. "Linux" is not "secure" neither, of course. But then, as soon as you give Jane Doe even access to the building where a LTSP network exists you gave away the first bit of security. There is no such thing as a 100% secure computer system, even the battery driven machine sunken in concrete and dropped down the Marianne fold theoretically could be tampered with. Admittedly, that machine would have a lot of "9" in their 99,999% security. Getting back to reality: By refusing to boot any tampered-with operating system from a strange DHCP server you probably gain the most important part. If you own a switch that allows to filter packets, you should disallow DHCPDISCOVERs to go anywhere but your DHCP server, and you are pretty much there. You should also hard-code the server IP to always belong to the appropriate MAC address, if your switch allows that, so that noone can impersonate your server (easily). Be aware that once that network card blows you will have to reconfig the switch. You better not restrict access to that single IP, then ;-) BTW restricting that MAC address to live behind the appropiate switch port would be a good idea as well. If you got that far, you probably do not need crypto in Etherboot. That was just an idea back when I implemented it, and might be reasonable in certain environments, but it has been nowhere near beta stage even. Those are my couple of cents. Best regards Anselm ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
