Suprimir archivos de recuperación al editar archivos confidenciales en vi, nvi y vim

Question

Estoy escribiendo una aplicación que mantiene una base de datos cifrada que contiene información extremadamente confidencial, incluidas claves criptográficas y contraseñas. La aplicación está paranoica con respecto al uso de memlock, el bloqueo de ptrace, la prevención de volcados de núcleo, etc., pero tiene un comando que permite al propietario de la base de datos editar el contenido de la base de datos. Este comando escribe toda la base de datos en un archivo temporal en formato ASCII legible por humanos y permite al usuario editarlo. Específicamente, crea un nuevo archivo en un directorio recién creado /tmp/XXXXXXXX/(donde /tmp es idealmente un sistema de archivos de memoria) y luego ejecuta el editor preferido del usuario en el archivo. Cuando se cierra el editor, la aplicación analiza el contenido del archivo y lo destruye y todo lo demás /tmp/XXXXXXXX/antes de eliminar finalmente el directorio.

Desafortunadamente, esta estrategia no funciona muy bien con ninguna de las variantes de vi, porque el editor termina escribiendo copias del archivo en /var/tmp/vi.recover, donde probablemente persistirán en el disco incluso después de que vi las elimine. (Los datos contienen claves privadas de alto valor, para las cuales sería fácil buscar en una partición sin formato completa). Estoy buscando una forma genérica de suprimir estos archivos de recuperación, o al menos moverlos a /tmp/XXXXXXXX/.

Mi solución ideal funcionaría para la mayoría de las variantes de vi, pero también estoy feliz de analizar la EDITORvariable de entorno y hacer algo diferente para cada editor. Por lo tanto, si tiene una solución que funciona para vim pero no para los demás, al menos es un buen comienzo. (Ya utilicé un caso especial de vim para volver a abrir el editor en el número de columna exacto de un error de análisis, mientras que otras variantes de vi solo se pueden abrir en la línea apropiada).

Como se trata de una aplicación que se distribuirá a otras personas, lo único que no puedo hacer es resolver el problema editando los archivos .exrc o .vimrc de las personas. En caso de necesidad, supongo que podría cambiar la variable de entorno HOME antes de ejecutar el editor y crear un .vimrc temporal que combine el real del usuario con algunos comandos de recuperación-supresión. Sin embargo, preferiría una solución de línea de comandos o comentarios.

Lo más cerca que puedo llegar a un ejemplo de trabajo mínimo es compartir lo que hago para emacs, que es agregar el siguiente comentario al final del archivo:

# Local Variables:
# make-backup-files: nil
# auto-save-default: nil
# End:

Aunque lo más fácil es una opción de línea de comandos, si algún comentario equivalente puede funcionar para vim o cualquiera de las otras variantes de vi, también sería genial.

actualizar:

Después de experimentar un poco con strace, parece el siguiente comandopodríahacer lo que quiero para vim:

vim -n -c 'set viminfo=' /tmp/XXX/secret.ini

Sin embargo, no funciona con --cmd, que fue la opción sugerida, sino sólo con -c. Además, realmente no entiendo qué -nhace, pero acabo de notar que la página de manual decía que interrumpirá la recuperación. Así que todavía me encantaría escuchar una respuesta de alguien con conocimientos sobre vim, si es que esto funciona. Y, por supuesto, serían bienvenidas soluciones para las otras variantes de vi.

actualización 2:

La variable de entorno EXINITpodríaFunciona para vi y nvi, si lo configuro en EXINIT=set dir=/tmp/XXX|set recdir=. nvi da una advertencia sobre la falta de recuperación al inicio, lo cual es alentador, mientras que vi coloca archivos en el sistema de archivos, pero al menos están en /tmp, que suele ser un sistema de archivos de memoria.

Answer 1

Para vimque pueda mover la ubicación del archivo de recuperación con eldirectoryopción.

set directory=/tmp/XXXXXXXX

Esto se puede agregar a la línea de comando para una sola instancia como esta

mkdir -m700 /tmp/xyz
vim --cmd "set directory=/tmp/xyz" /path/to/secure.file

Answer 2

Se me ocurren varias opciones para ofrecer a los usuarios un editor razonable con la mayor paranoia posible. Dado que se trata de una aplicación sensible a la seguridad, tómelo todo con cautela y corrija cualquier error.

Sugeriría hacer una de estas cosas de forma predeterminada, pero haciendo posible, de una manera claramente documentada, que las personas usen la suya propia vimcomo una opción claramente documentada para que no intenten copiar datos fuera del archivo bloqueado vi.

Además, algunas de estas sugerencias (en particular, jugar con LD_PRELOAD) pueden ser totalmente inaceptables, estar deshabilitadas (en la medida de lo posible) o estar limitadas en su entorno.

Aquí hay algunas opciones potencialmente excluyentes entre sí sin ningún orden en particular,

1. ejecute el editor como un usuario sin privilegios, como sudoeditlo hace.
2. proporcione a su propio editor funciones que no desea parchear ni compilar
3. interceptar llamadas a libcfunciones problemáticas con LD_PRELOAD.
4. omitir el del usuario .vimrcpor completo.

1) ejecute el editor como usuario sin privilegios

Si tiene la capacidad de crear usuarios adicionales o exigir que las personas que usan el software creen un usuario dedicado sin privilegios, entonces puede usar el mismo truco que sudoeditusa: crear un archivo temporal y hacer que el usuario lo edite como usuario sin privilegios. No sé cómo garantizar que el archivo temporal nunca toque el disco.

Parece que ya estás haciendo algo similar a esto, pero sin el usuario sin privilegios.

Aquí está unrespuesta de superusuario explicando cómo sudoeditfunciona.

Además, recomendaría estudiar cómo funciona la sudoeditfuncionalidad sudo.aquí hay un código relevante.

2) empaqueta el tuyo propio vi.

nvies pequeño y tiene licencia BSD, es posible que pueda parchearlo para que nunca cree archivos de intercambio o lo compile sin soporte para archivos de intercambio. En realidad no lo sé porque la última vez que intenté compilar nvino pude descubrir cómo hacer que su versión antigua de autotools detectara OS X.

Como parte de la construcción de su producto principal, puede tomar el hash de su nviejecutable y incorporarlo como una constante de tiempo de construcción.

Los usuarios de Emacs pueden obtener una copia de mg. Aquí está unenlace a un tenedor de mg. La variante que realmente vive en el árbol de fuentes de OpenBSD tiene licencia ISC. Es posible que necesites parchearlo porque a veces falla (por ejemplo, para interactuar con cscope).

Creo que los usuarios de nano no tienen suerte.

3)LD_PRELOAD

utilícelo LD_PRELOADpara indicar ld.so(en Linux) que se cargue un shim para interceptar llamadas a libcfunciones como fwrite, fork, &c.

4) omita las opciones de configuración del usuario en vim, en su lugar ejecute su propia configuración mínima.

Esta es la línea de comando más segura que vimse me ocurre, pero es posible que me haya perdido algo. Solo lo obtuve leyendo la página de manual de vim y mirando mi archivo .vimrc.

• -u NONE-- sin inicialización
• -i NONE-- No.viminfo
• -U NONE-- sin inicialización ( gvimpero bueno, nunca se puede ser demasiado cuidadoso)
• -Z - empieza como si lo argv[0]fueras rvim.
• set nocompatible-- no seas vicompatible.
• set backspace=indent,eol,start-- hacer que el retroceso sea más intuitivo
• set noexrc- probablemente redundante, no lea ningún rcarchivo.
• set secure-- no autocmd, no shell, no write, mostrar -- mapcomandos.
• set nobackup-- no hay opciones de respaldo
• set laststatus=2-- muestra el archivo que estás editando

Entonces, aquí está la línea de comando que lo reúne todo.

vim -n -u NONE -i NONE -U NONE -Z \
        --cmd "set nocompatible | set backspace=indent,eol,start | set noexrc | set secure | set nomodeline | set nobackup | set laststatus=2" \
         --