Ejecutando shred en un archivo en la memoria no tiene sentido. También es probable que los datos del archivo estén presentes en la memoria de la aplicación, en cachés, etc. La memoria que pertenecía a un proceso no se borra cuando el proceso muere:Linux, como la mayoría de los núcleos, borra la memoria antes de dársela a un proceso, no en el lanzamiento, porque eso es más rápido.
Por supuesto, no hay garantía de que el archivo pueda ser recuperado Pero tampoco hay garantía de que no pueda. Si su modelo de atacante es que el atacante puede ver su contenido de RAM, hay muchas cosas de las que debe ocuparse. Como mínimo, debe borrar las páginas de RAM tan pronto como el proceso las libere. Puede aplicar los parches de Grsecurity al kernel de Linux, al menos el PAX_MEMORY_SANITIZE opción. Y debe tener cuidado con los procesos que se están ejecutando y podrían almacenar información confidencial. Y tenga en cuenta que el núcleo también almacena información confidencial, como el estado RNG y las claves de cifrado del disco. El parche TRESOR para el kernel de Linux protege las claves de cifrado del disco durante el funcionamiento normal, pero no es una defensa perfecta y no conozco un parche similar para el estado RNG.
El peligro que está tratando de mitigar es el diario del sistema de archivos, es decir, shred no es efectivo en sistemas de archivos que tienen un diario (por ejemplo, ext3, ext4, reiserfs).
Asumiendo que no estás usando ningún unionfs para la persistencia (aparentemente puedes hacerlo en Tails aunque nunca lo intenté), todo se almacena en un tmpfs .
La documentación de Linux en tmpfs no detalla si se realiza el registro por diario. Sin embargo, tmpfs se basa en ramfs , el mismo sistema de archivos que se usa en initramfs , y ese sistema de archivos no tiene un diario. Por lo tanto, es (más o menos) seguro asumir que tmpfs tampoco tiene un diario.
En un sistema de archivos sin diario shred realizará la sobrescritura del archivo, lo que dificultará la recuperación con herramientas analíticas (prácticamente imposible de recuperar de un volcado de RAM). Ya que todo sucede en páginas de memoria, y los inodos de un tmpfs simplemente apunte a las páginas de memoria, usando shred es mucho mejor porque podrá escribir en estas páginas de memoria.
Advertencia
Lo anterior ciertamente funciona de esta manera en Tails y en Knoppix. Es probable que funcione de manera similar en casi todas las distribuciones de Linux en LiveCD, incluido Kali Linux, pero hay una advertencia .
¡Esto funciona para archivos! La memoria también contendrá la memoria de la aplicación, consulte la respuesta de Gilles sobre la memoria de la aplicación. En serio, mira esa respuesta, abre un punto importante.
Además, una distribución basada en Ubuntu Linux (que puede o no incluir Kali Linux* ya que su predecesor, Backtrack, estaba basado en Ubuntu) montará cualquier intercambio que encuentre en la máquina que arranca, ¡lo que puede dejar un vector de ataque mucho peor! ¡Datos persistentes en el propio dispositivo!
Otra advertencia con Kali Linux es que viene con metasploit y arranca el postgres base de datos para usar con metasploit . Postgres tiene su propio diario (que se basa en archivos, no en sistemas de archivos), que es posible que desee triturar también (es decir, triturar los archivos de Postgres, no solo eliminar los datos a través de psql ).
* Kali no está basado en Ubuntu, está basado en Debian, pero no estoy seguro de si eliminó todos sus scripts de configuración desde el momento en que se llamó Backtrack y estaba basado en Ubuntu