On Monday 26 August 2002 02:31, S Mohan wrote: > Went thro' cramfs documentation and creation methodology in > www.handhelds.org howto. If this can create a ro filesystem which can > never be made rw, is it not better than mounting a tmpfs as ro which > can be changed to rw by a hacker?
To write things such as logs and dhcp leases, some part of the system much be rw. A compromised box can be made to symlink to a file that the hacker could put on the rw partition. Software protection will never be as safe as hardware protection. This idea is fine, but the issues that each type appoach are different and cramfs can only be used where _no_ writing is ever necessary or desired. > Just FYI, WISP-Dist uses CramFS for binaries, so they are > read-only. However, a knowledgeable hacker would still be able to > find the location of the parent MS-DOS partition and tamper it, > however it is a very tricky task if you want to be unnoticed. This is cool, but does it prevent placement of a hostile binary in an alternate location and symlinking it to override the original??? > > If I'm not wrong, /dev requires rw. Why not > > declare as a separate partion in linuxrc when generating /dev > > directory? Locate mount and df in directories that are not in the > > path so that the hacker cannot get to it easily. In lrcfg, during > > backup, mount the device as rw, backup and then mount it back as > > ro. In Linux, EVERYTHING is a device. This would prevent sending information to anything including the console.... shoot even /dev/null is a device. > > Probably obvious to everyone here, but with all the emphasis > > on write-protected boot media lately, it might be worth mentioning > > that hardware write-protected boot media is only good if you detect > > when unauthorized changes are made to the > > (writable) ramdisk. It's not much good to have a clean boot image > > if you don't know to reboot and restore it. True. > > One approach to increasing protection afforded by the write- > > protected boot media would be to run the firewall in a nearly > > halted state as described in SysAdmin at > > although that approach has significant limitations...like not being > > able to run sshd for remote administration. Or write logs, or get a dhcp lease, or run dns-cache, or (possibly) use ipmasq/iptables. IIRC, only the kernel runs at runlevel 6. > > IMO, it would be really cool to augment the security of > > write-protected boot media with an integrity checking system. > > Possibly one that computes file checksums and compares them to > > known good checksums. Like Tripwire or AIDE I guess, although I > > haven't used either of those tools yet. Such a system would also > > make me feel more comfortable running compact flash LEAF boxen > > without boot media write protection. David D. indicated he was looking at incorporating something along these lines. I do not know if he has actually attempted an implementation though. <snip> > > Does anyone see flaws with the described approach that I > > have overlooked? > > > > Would anyone like to offer suggestions for improvements? > > It would be too hard to say w/o attempting it. It sounds like a good place to start with anyway! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
