in reply to "safe" perl cron environment?

Thanks to all who have posted, I think you've helped me understand better the issues.

As I mentioned, I'm primarily concerned with industrial espionage and someone trying to steal my proprietary algorithms.

There are a couple of scenerios for this:

1) Josephene hacker finds a here-to-fore unannounced / unpatched remote root exploit on my nearly inpenetratable system. Obviously, if there are no processes running as root and no root cron entries, this is much harder. She must resort to capturing a core image and decompiling.

2) Someone physically breaks into our plant and steals the HD out of the server. An encrypted filesystem and some sort of wipe-if-booting-out-of-my-environment boobytrap are the best options here.

3) The inside job (always the most probable):
3a) a rescue image boot -- see #2 above
3b) our sys-admin is payed off to steal the scripts -- Here the best defense is that he doesn't know the root password. That is probably workable in this case.

So the big questions remain where/how to store the key for the encrypted filesystem and how to implement a wipe-if-booting-out-of-my-environment boobytrap. Hmmmm...

john

Replies are listed 'Best First'.
Re: My conclusions
by BrowserUk (Patriarch) on Dec 03, 2002 at 23:10 UTC

    The wipe-if-booting option is probably inoperable as if I had stolen your drive, I wouldn't try and boot from it, I'd just view it as a secondary drive from my own system.

    As for storing the key(s) to your encrypted filesystem(s), probably the best place would be a microdrive or keyring memory device. You can put these in your pocket (or the safe) when you (or trusted surrogate) leave at night and replace them in a network attached drivebay/reader in the morning.

    Of course, this precludes your systems running 24/7.

    Alternatively, you could have the keys located on a remote (home?) system and require your systems to fetch the keys from that remote system (via SSL? or similar).

    You then have the problem that if one of your systems goes down, you (or your trusted surrogate) is needed to physically restart that system (as it would need your logon to make the connection to the key server).

    Then two places have to be physically compromised before you become vulnerable.

    Is this more than an academic exercise?

    Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
    Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
    Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
    Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]
      It is more than an academic exercise. I'll need to deploy in about six months. I'm still weighing the alternatives.

      The simplest case is just set everything important (including Perl) to root owned, read only mode 500. (Ok, maybe perl can be executed by other), kill all non-essentials and then hope noone finds an exploit. It doesn't help with the stolen disk problem, but it is easy and works fine out of the box.

      There's also another solution that came up -- using public key crypto you can do a reatime mixmaster type deal where the key is stored locally and requires decryption from a number of cooperative servers -- the key finally arrives only encoded with a local key and can be decoded and used, but never stored. Temporary session keys protect the individual transmissions. It's clunky, but I believe that if done correctly it requires the hacker to have to hack each participating system to steal the key. It also requires some fancy code signing to make sure the program that implements it has integrety.

      That sounds like a fun crypto problem, but I'm not sure I want to spend my time that way.

      john

[reply]

In Section Seekers of Perl Wisdom