Timeline for Implications of securing data in RAM
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 4, 2012 at 14:12 | comment | added | Polynomial | @curiousguy Figured as much. I'm not that familiar with Linux hardening, but I had a feeling such a thing wouldn't be allowed. | |
| Jul 3, 2012 at 18:10 | comment | added | Gilles 'SO- stop being evil' | Your first and last sentences are too peremptory. It depends what the flow of data is, as you discuss in between. | |
| Jul 3, 2012 at 16:25 | comment | added | curiousguy |
@Polynomial "that allow /dev/kmem access to root" I believe this is usually turned off on "harden" sensitive systems
|
|
| Jul 3, 2012 at 15:42 | comment | added | Polynomial | Alternatively, they could use a HSM. | |
| Jul 3, 2012 at 15:41 | comment | added | Polynomial |
One improvement on this is to store the encrypted data in nonpaged pool via a kernel module. That way you're placing the data in the same area of the system that you would consider the final bastion of integrity. Once kernel-mode is compromised, the entire box is compromised. Not sure how this stacks up on Linux systems that allow /dev/kmem access to root, but at least it adds an element of complexity to a potential attack.
|
|
| Jul 3, 2012 at 15:25 | history | migrated | from programmers.stackexchange.com (revisions) | ||
| Jul 3, 2012 at 14:51 | history | answered | Gary | CC BY-SA 3.0 |