If you make it read-only you don't need logs. During your period upgrades, get a SHA sum of the whole partition. Make sure that matches the standard.
On Wed, Nov 18, 2009 at 15:01, Ted Stern <[email protected]> wrote: > 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 >
