Charles, your argument is correct, if you can store _AND_ execute files. If you partition the file system, that you can write only to file systems where you cannot execute, I think it would be very difficult if not impossible to access the boot device.
Is there a way to modify the memory and execute the modified memory without a debugger? OTOH is it not better to have a write protection that is not perfect than to have none? Manfred Charles Steinkuehler schrieb: > > > What if during the initial boot process you mount your hard disk as a > > read-only device then delete the mount command? Would this be sufficient > > protection for a HD? (i.e. Is there any other program that could be used > > to remount the HD?) > > > > Saving config changes could be handled by mounting a config floppy during > > the init process that never gets umounted during normal operation. > > This definately throws up a road-block, but as with any software write > protect, it can ultimately be undone. > > If only software (or a lack thereof) prevents writing to your storage media, > and you assume some nasty has obtained root access, it's only a matter of > how many hoops you have to jump through... > > Don't have a mount command? Copy it off the 'net or call the kernel > functions to mount directly from your HackerApp. > > No utilities to copy from the 'net? Cobble something together with nc, or > just "echo -e "\000\001\002" >HackerApp.bin until you've got the whole > executable. > > Removed the kernel module to talk to your storage device? Just copy or > re-build it (same as above). > > Swapped to a new kernel that doesn't have modular support, and doesn't know > how to talk to your storage device? Just talk to the hardware > directly...it's not that hard to read/write directly to an IDE device with > no OS intervention. > > And so on... > > In general, if something's write-protected by software, it can be > un-write-protected by software with enough determination, cleverness, and > access privliges. The exception is in some embedded systems, where they > specifically create hardware write-protection that's triggerable by software > (but this is fundamentally hardware write protection, not software > write-protection). Basically, software can access a device until such time > as the software goes through a (usually somewhat convoluted, to avoid > accidents) locking process. At this point, the hardware write-protectes > itself, and does not reset without a cold boot, or some other form of manual > intervention (perhaps pressing a reset button or something). > > Charles Steinkuehler > http://lrp.steinkuehler.net > http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) > > _______________________________________________ > Leaf-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
