Somebody in the thread at some point said: > On Tuesday 23 October 2007 08:19:30 bob.smith@xxxxxxxxxxx wrote: >> The idea was to create sort of(in some way) "encrypted and protected" >> executables. This to be able to verify that an executable is what it >> is(located on machine X, and compiled on machine x). Further, the >> executable would be made so that it could not run on a system on which it >> was not allowed to run. That was the basis of the idea. Purely theoretical. >> How this could be achieved in reality is beyond my current knowledgebase, >> but I am sure that someone else with more knowledge in encryption and >> protection than me, could maybe analyse this further. >> > > A small approach to this, I mean to be sure that the executable is the one you > installed firstly, could be getting the filehash of all the binaries You can cryptographically sign a hash of the executable and append the signature to the executable itself. That way they can discover tampering or change because the bad guy can't regenerate the sig as he lacks both keys. Basically migrate the RPM package signing down into the contents. But it seems to me it's not where the real problems are for servers. The real problems are in PHP or other scripts that accept user input as PHP code or database queries one way or another, and it won't really help since the attacker is running the properly signed stuff. There's a lot of bad things the attacker can do with PHP commands, shell commands, alias, config files, etc that all run in 'authorized' contexts. The recent vuln in Tikiwiki is a case in point... -Andy -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
