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?
Will jnilo and ewolzak look at incorporating cramfs in rc4? Is it feasible or out of scope...? Will cramfs make the distro too big for 1 floppy? From what I could gather in the mailing list, most of us are now using or looking at flash/ cf/ sm/mmc as alternatives to floppies which will make space issue irrelevant. Mohan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vladimir I. Sent: 26 August 2002 07:52 To: S Mohan Cc: 'Brad Fritz'; [EMAIL PROTECTED] Subject: Re: [leaf-user] [long] boot media write protection and change detection (was: Are there other "Soekris"...) 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. S Mohan wrote about "RE: [leaf-user] [long] boot media write protection and change detection (was: Are there other "Soekris"...)": > Is it possible to segregate the area that requires write permissions as > one ramdisk partition, mount is as rw and mount the other portion as ro? > 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. > > I'm not very dexterous with linux boot sequence. If my idea makes sense, > can this be incorporated by someone more skilled please? > > Mohan > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Fritz > Sent: Sunday, August 25, 2002 9:41 AM > To: [EMAIL PROTECTED] > Subject: [leaf-user] [long] boot media write protection and change > detection (was: Are there other "Soekris"...) > > > > On Sat, 24 Aug 2002 13:35:18 MST Craig wrote: > > > Are there other "svelte" looking devices that LEAF can be installed on > > > like these Soekris type devices > > [snip] > > > Are these devices really "secure" in the sense > > that they're somehow read only like a write protected floppy or CD-R? > > > 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. > > 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 > > http://www.samag.com/documents/s=1824/sam0201d/0201d.htm > > although that approach has significant limitations...like not being able > to run sshd for remote administration. > > 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. > > Computing checksums on low-end LEAF boxes might not be a great idea, so > I was thinking of an approach like this... > > 1. Setup a central, well-protected management server that > has ssh public-key access to the LEAF servers to be > monitored. The management server would have ssh, rsync > and a tripwire(-like) package installed. (Actually I > already have this system setup minus tripwire/aide.) > > 2. At regular intervals the management server would use > rsync over ssh (with public key authentication) to update > a local copy of the remote LEAF file system.[1] > > 3. The tripwire(-like) tool would be run on the local copy of > the remote image to compare file signatures to known > good signatures in a database. An administrator would > be notified if signatures of important files had changed. > > One of the weaknesses of the system would be that a skilled attacker > could replace sshd with a modified version that spits back archived > original copies of the checked files rather than the versions in > service. If rsync is being used, it would probably be even easier to > deceive the management host. > > Alright, enough of my rambling; just a few questions and then > I will wrap it up... > > Is anyone here already doing something like this with LEAF? > > Does anyone see flaws with the described approach that I > have overlooked? > > Would anyone like to offer suggestions for improvements? > > > --Brad > > [1] Using rsync would be optional. A full copy could be > transferred if network bandwidth is more plentiful than > spare CPU cycles on the LEAF system. > > > > > ------------------------------------------------------- > 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 > > > > > ------------------------------------------------------- > 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 -- Best Regards, Vladimir Systems Engineer (RHCE) ------------------------------------------------------- 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 ------------------------------------------------------- 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
