Hi, there's no way to provide absolute security in some cases, especially when things are expected to run unattended ;-). Sorry, I don't have any new suggestion to avoid remote root vulnerabilities, but I think I could offer a small amount of security enhancement regarding theft. What about having the perl script live in an encrpyted file system (using the sources at http://www.kerneli.org, for instance). The key needed to mount the encrypted file system will stay in RAM, only, and thieves usually don't have electricity available during their operations. Have the key on another, remote system, and write a "key fetching tool", with a client on the target system and a server on the remote machine. Use, say, OpenSSL to authenticate the parties and keep the traffic encrypted, and have the daemon check the IP address and maybe the route the IP packages take between key server and client before transmitting the key. Obviously, the key server must be kept safe and secure, very much like the target machine. With a setup like this, you'd have to steal two boxes from different locations to read the Perl stuff. Depending on the amount of bucks involved, you could even share the key between several key servers at different locations ;-) Regards, Ernst On Fri, 2003-01-24 at 19:58, John Hanna wrote: > Hi. Let's assume someone wrote a perl script that figured out how to make a > lot of money on the stock market, but that they wanted to protect the script > because if others began using it, it would dimish its returns. The new > millionaire would want to protect her creation, but it has to run on a > computer with access to the internet. She puts it on a box which she tries > to keep patched, it's behind a firewall, and only root has access to the > scripts. The scripts need to run unattended, and the system needs to boot > unattended. She fears two things: a remote root vulnerability, and that > someone would physically walk off with the box. > > My impression is that under these conditions, besides vigilance, limiting > running processes, working on physical security, keeping up on patches, > possibly some sort of IDS -- there really isn't anything she can do to > protect the source. If it's booting unattended, and running scripts > unattended there's no sort of crypto strategy that could protect either > against an intruder with root access or physical access to the hard drive. > > What do you think? > John
This archive was generated by hypermail 2b30 : Sat Jan 25 2003 - 01:15:47 PST