On 18 Nov 2009 14:13:08 -0800, Derek Simkowiak wrote: > > Good info... interesting stuff. > > But one could argue that a read-only O.S. partition goes against > the goal of security. Part of "security" is change management, > auditing of log files, and updated software. > > With the ZFS+RAM disk model, you could wind up running un-patched > software everytime you reboot. And if the system gets attacked while > running, any audit trail (relevant log files) would also get wiped at > reboot. Intrusion detection systems and C.M. software (e.g. Tripwire) > would have their databases reverted at every reboot. And there will > be headaches dealing with files like /etc/ssh/ssh_host_rsa_key and > /etc/ssl/certs/root.pem (which are supposed to be unique for each > computer). > > There's something to be said for thin clients with read-only > firmware, but if you want a fully functional Linux system > (incl. software updates and network daemons) I think the O.S. has to > be writable.
OP here. I can't sell the idea of having automatic security updates from outside the secure firewall, so change management needs a different paradigm. I envision OS updates being done offline: once every couple of days you plug your USB key into a secure workstation and write an updated OS onto it. That could be coordinated with virus-checking and backing up /home. So maybe there's a way to make the OS without it being read-only: you could use that same docking time to scan the OS partition to check logs and see whether any exploits have been attempted. Ted > > --Derek > > On 11/18/2009 01:53 PM, Keziah Wesley wrote: >> No need to load the whole r/o partition into the ram disk though - >> I haven't researched the details but I'm thinking you could: >> - use ZFS >> - use ZFS's integrated LVM capabilities to include a ram disk device >> and your r/o partition in the same filesystem, with the ram disk as / and >> the r/o stuff under a /ro subdirectory >> - cp -R /ro/* / >> - because of ZFS deduplication, the ram disk will now be using almost no >> space because every file is really a pointer to the /ro version. When a file >> under / is modified, however, the pointer is replaced with the new content. >> >> Pro: a filesystem that is read-only on disk but read-write while running, >> as loading all the content into a ram disk would be, except the ram disk >> will only take as much space as the files that are actually modified (a very >> small portion) >> Con: more complicated to implement; most systems these days have enough >> RAM that unless you're requiring a huge USB stick for your read-only content, >> you don't really need the space anyway. >> >> tl;dr: use ZFS's LVM & dedup to create a smart "sparse" ram disk. >> >> Just sayin'. >> >> -Kz >> >> On Wed, Nov 18, 2009 at 13:27, Chad R Mayfield <[email protected]> >> wrote: >> >>> It has partially been done by a few people. The one that sticks out in my >>> mind is, http://bcable.net/system.php. Of course this is using a customized >>> GRML live cd and loaded into a ramdrive each boot, but I don't see why you >>> could not do something similar with a flash drive. >>> >>> --- >>> Chad R Mayfield >>> [email protected] >>> GPG Key: 0C9A026F >>> http://www.planetmayfield.com/ >>> http://www.chadmayfield.com/ >>> http://www.linkedin.com/in/chadmayfield >>> >>> > -- Frango ut patefaciam -- I break so that I may reveal
