h a l f b a k e r yLike a magnifying lens, only with rocks.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
|
Would you have to flick the switch to install software? Or change settings? |
|
|
I'm afraid it will have to include change to settings as well. |
|
|
You can disable writing to the boot sector in the BIOS. |
|
|
DIY is right. The boot sector can be locked by the bios, to my knowledge this software layer has never been indirectly defeated. |
|
|
But that still leaves rest of the OS vulnerable. |
|
|
Except for its size, the OS is the least of what needs to be protected: that can always be reloaded. |
|
|
Personal media, personal info, archives, etc. : most everything on a PC is read-only. |
|
|
//Except for its size, the OS is the least of what needs to be protected: that can always be reloaded.
Personal media, personal info, archives, etc. : most everything on a PC is read-only.// |
|
|
If the proposed system was intended to protect personal files, it would be effectively essential to be able to write new files to the hard-disk section (as opposed to editing existing files). As otherwise the switch will soon be set to off and left there by virtually all users. This requirement would naturally make secure implementation more difficult. |
|
|
Furthermore, it _is_ important to protect the OS - deleting/ corrupting/ holding-to-ransom irreplaceable files is not the only security risk. Denial of service and theft of private information (eg. banking data or personal material) are two threats which spring to mind.
If one ignores the OS, then it would be fairly simple for malware to hang around in stealth mode until it detected that the switch was flicked off... |
|
|
Data Execution Prevention (DEP) is a CPU instruction which when enabled prevents the OS from running code in areas that are supposed to contain data rather than instructions. |
|
|
Let's consider how Data Write Prevention would work with a mechanical switch. Each time the computer is powered up, the kernel must be loaded into memory. Would a CPU instruction enable RAM locking only after the OS has loaded? Wouldn't the machine remain vulnerable during boot? Sections of ROM and RAM would need to be marked somehow. This could be baked with a new filesystem and similar techniques as used in DEP. |
|
|
The kernel is only a small attack vector, so I wonder about the cost/benefit to such a facility. |
|
|
ed, OS should be loaded in flash -memory, the instant boot PCs kind. Once it is loaded, it will always be there. |
|
|
Similar kind of protection can be given to critical applications, such as banking, medical etc. |
|
|
In these cases, flash memory can be used for OS as well as applications. Only data should be stored in RAM, IMHO. |
|
|
// Only data should be stored in RAM // |
|
|
Ask yourself why BIOS and Option ROMs are shadowed to RAM. |
|
|
The answer is access time; RAM offers the shortest fetch time to the CPU. |
|
|
Flash memory has a limited cycle life. |
|
|
Microsoft won't like this idea. |
|
|
I've had the frustrating experience of trying to recover data from a failing external hard disk, while Windows kept corrupting the disk and generating endless "delayed write failed" errors by trying to leave its droppings. I gave up and tried to mount it read-only on a Linux machine, but the damage had been done and I lost nearly everything. |
|
|
A physical read-only switch would have been welcome. |
|
|
Another use is for live, non-persistent operating systems such as Tails. |
|
| |