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
