ben mord wrote original message from crispin cowan mailto crispin wirex com sent wednesday september NUMBER NUMBER NUMBER NUMBER pm to ben mord cc webappsec securityfocus com secprog securityfocus subject re use of base image delta image for automated recovery from attacks ben mord wrote i was inspired by a mode of operation supported by vmware use vmware s ability to rolll back state to recover from intrusions i did my dissertation work in this area optimistic computing URL and so was interested in applying it to the security problem unfortunately you hit a bunch of problems when can you commit a state as being good you can t run from a redo log forever the performance and storage penalties accumulate even log structured file systems garbage collect eventually so you have to commit sometime the problem is that if you commit too eagerly you might commit corrupted state if you commit too conservatively you eat performance and storage penalties what do you do if you discover that there is corrupted state in the middle of your redo log and you want some of the critical state that comes after it you need some way to dig the corruption out of the middle and save the rest my dissertation solves this problem but you have to re write everything in my programming language just doing this at all imposes substantial performance penalties i love vmware and use it every day the best NUMBER i ever spent on software but it is not very fast my proposed solution to the first two problems you mention is to be less ambitious the idea is that you never commit instead you simply revert to base state on reboot ah in that case you can use something considerably less powerful than vmware all you need is a machine configured to boot from cd rom and use a ram disk for scratch space numerous linux distros are available that let you boot a stateless but functional system from cd rom obviously you can t do this with partitions that accrue important state e g a partition that stores database table data but if you do want some state to persist then you need a mountable writable partition to protect it you need some kind of access control management to decide who can do what to the writable partition blah blah blah and before you know it the security problem starts to look just like it does for conventional servers simple approxmation to this make usr a separate partion and mount it read only the good news attackers that want to trojan your software have to reboot at least the bad news administrators that want to update your software have to reboot at least crispin crispin cowan ph d chief scientist wirex URL security hardened linux distribution URL available for purchase URL 