Secure text editor?
vesely at tana.it
Tue May 15 11:44:05 CEST 2007
Peter S. May wrote:
> Peter Lebbing wrote:
>> an editor which will not leak the text in any way, so locking it's pages in
>> memory so they won't be swapped out, and other angles of attack.
> (Developers familiar with swap-locked memory: I'd appreciate at least a
> short explanation of how it works to someone who understands ISO C but
> not necessarily OS-specific APIs.
Virtual memory is a feature that an OS can expose to apps. Memory mapped
files are an example. On Linux there are both shm and mmap. Traditional
SysV stuff may better suit inter-process sharing, while more recent APIs
emphasize multi-threading within the same process. On Windows there is
just one way to share memory. Memory locking must be understood in that
context. It is meant for synchronization purposes, not for security.
How to _avoid_ to share memory is a different subject. Apps don't make
decisions on system resources. Using a swap file is a system decision,
and it should be configured accordingly. Even if you have no swap file,
you can still *debug* an app. That implies the ability for an external
process to poke its nose into the app's memory, swapped or not. On Linux
it is somewhat easier than on Windows to examine other processes' memory.
Only the kernel can hide memory from apps. In theory, it can also hide it
from device drivers, on CPUs that implement multiple rings.
On Windows, it is a common habit to assume that users have no control over
what software is installed or runs on their systems at any given time.
Maybe, that's why Vista crypts intra-system (kernel-device) communication.
However, the latter feature adds no security, from a user's perspective.
On Linux it is more common to consider that a system is compromised if it
contains any software that is not trusted. Other communities consider
compromised a system if it is, or has ever been, connected to the Internet...
Finally, for the editor, let me mention Emacs:
More information about the Gnupg-users