Escriba una vez, lea muchos (WORM) usando el sistema de archivos Linux

8

Tengo el requisito de escribir archivos en un sistema de archivos de Linux que no pueda sobrescribirse, agregarse, actualizarse o eliminarse posteriormente. No por un sudo-er, root, o cualquiera. Estoy tratando de cumplir con los requisitos de las regulaciones de servicios financieros para el mantenimiento de registros, FINRA 17A-4, que básicamente requiere que los documentos electrónicos se escriban en dispositivos WORM (escriba una vez, lea muchos). Me gustaría mucho evitar tener que usar DVD o dispositivos caros de EMC Centera.

¿Existe un sistema de archivos Linux, o puede SELinux soportar el requisito de que los archivos se completen de manera inmutable inmediatamente (o al menos pronto) después de la escritura? ¿O alguien está al tanto de una forma en que podría aplicar esto en un sistema de archivos existente usando permisos de Linux, etc.?

Entiendo que puedo establecer permisos de solo lectura y el atributo inmutable. Pero, por supuesto, espero que un usuario root pueda desarmarlos.

Pensé en almacenar datos en pequeños volúmenes que se desmontan y luego se vuelven a montar de solo lectura, pero luego creo que la raíz aún se puede desmontar y volver a montar como de escritura.

Estoy buscando ideas inteligentes, y en el peor de los casos, estoy dispuesto a hacer una pequeña codificación para 'mejorar' un sistema de archivos existente para proporcionar esto. Suponiendo que haya un sistema de archivos que sea un buen punto de partida. Y establezca un servidor Linux cuidadosamente configurado para que actúe como este tipo de dispositivo de almacenamiento en red, sin hacer nada más.

¡Después de todo eso, el cifrado en los archivos también sería útil!

— phil_ayres
fuente

44

Lo que estás pidiendo no se puede hacer. Si tiene acceso de root a la máquina, puede realizar operaciones a nivel de bloque directamente en el disco. Por lo tanto, no importa qué sistema de archivos esté en la parte superior, no puede proteger nada de la raíz, solo puede ralentizarlo o hacerlo tan oscuro que parezca seguro.

— Regan

Después de leer la interpretación de la SEC sec.gov/rules/interp/34-47806.htm , voy a estar de acuerdo con @Regan. Sin embargo, todo esto es un poco absurdo. Por ejemplo, ¿cómo se borra un CD? Con fuego, por supuesto.

— Mark Wagner

Estoy totalmente de acuerdo en que los requisitos son "ligeramente absurdos". Están tratando de hacer que sea tan obvio que se ha intentado ocultar la verdad de que ningún técnico de TI estaría de acuerdo en hacer lo que un ejecutivo no bueno está pidiendo. Al parecer, presionar eliminar en un directorio grande como root era demasiado fácil para alguien. La destrucción física se convierte en la única forma de encubrir las cosas en las reglas de la SEC.

— phil_ayres

nombre de archivo chattr + i, debe dar este comando cada vez que cree un archivo

— c4f4t0r

@ c4f4t0r no se detiene: chattr -i filenameentonces rm

— phil_ayres

2

Puede hacer esto con OpenAFS y volúmenes de solo lectura. Sin embargo, es necesario instalar mucha infraestructura para que funcione y es posible que no cumpla con los requisitos.

http://www.openafs.org/

Básicamente, hay un volumen grabable y una o más copias de solo lectura del volumen. Hasta que libere el volumen grabable, las copias de solo lectura no se pueden cambiar a los clientes. Liberar el volumen requiere privilegios de administrador.

Parece que cualquier solución requeriría hardware especializado o un sistema de archivos de red que duplique la semántica del hardware especializado.

— Fred the Magic Wonder Dog
fuente

¿OpenAFS realmente evita que la raíz escriba en el volumen de solo lectura? No pude encontrar una definición definitiva en los documentos.

— phil_ayres

Ciertamente evita que la raíz en el cliente escriba en los volúmenes ro. En general, root no implica ningún permiso especial en OpenAFS.

— Fred the Magic Wonder Dog

1

Parece que no hay forma de hacerlo sin escribir un código personalizado del sistema de archivos / kernel.

Una solución viable parece ser usar Amazon Glacier con la opción de almacenamiento de archivos WORM. De acuerdo con el Blog oficial de AWS en: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] una nueva función Glacier que le permite bloquear su bóveda con una variedad de controles de cumplimiento diseñados para soportar este importante caso de uso de retención de registros. Ahora puede crear una política de bloqueo de bóveda en una bóveda y bloquearla. Una vez bloqueada, la política no se puede sobrescribir ni eliminar. Glacier hará cumplir la política y protegerá sus registros de acuerdo con los controles (incluido un período de retención predefinido) especificados en él.

No puede cambiar la política de bloqueo de bóveda después de bloquearla. Sin embargo, aún puede alterar y configurar los controles de acceso que no están relacionados con el cumplimiento mediante el uso de una política de acceso de bóveda separada. Por ejemplo, puede otorgar acceso de lectura a socios comerciales o terceros designados (como a veces lo exige la regulación).

Para mí, esto proporciona exactamente lo que se necesita sin el gasto del hardware de NetApp o EMC, al tiempo que parece cumplir con los requisitos de retención de registros.

— phil_ayres
fuente

No hay diferencia lógica de mi solución. El administrador del servidor, en este caso Amazon, aún puede borrar o alterar algunos o todos los archivos. La única diferencia aquí es el proveedor de almacenamiento de archivos ...?

— nrc

Lo tiene exactamente en su suposición de que el proveedor de almacenamiento es la verdadera diferencia. Con un administrador interno del servidor, el regulador cree que pueden ser manipulados por una persona de mayor rango en la misma organización para eliminar o alterar registros. Por supuesto, podría pedirle a alguien en Amazon que destruya todo, pero se supone que habrá un rastro de papel y hay una mayor probabilidad de que una solicitud inesperada sea rechazada. No es tan bueno como el fideicomiso formal, pero separar las responsabilidades proporciona gran parte de la protección que se necesita.

— phil_ayres

1

Todavía puede eliminar los archivos al dejar de pagar por el almacenamiento.

— Tomas Zubiri

0

Si simplemente necesita acceder a archivos desde un sistema en el que los usuarios no pueden sobrescribirlos, puede montar un volumen remoto en el que no tiene permiso de escritura. La manera más fácil de hacer esto es montar un recurso compartido de solo lectura samba / cifs.

De lo contrario, si necesita una forma de permitir que los usuarios escriban nuevos archivos (que no se pueden sobrescribir o modificar), una solución es montar una ruta FTP con FUSE curlftpfs.

Puede configurar su directorio proftpd con estas directivas:

AllowOverwrite off
<Limit WRITE>
  DenyAll
</Limit>
<Limit STOR>
  AllowAll
</Limit>

De esta forma, los archivos nuevos se pueden almacenar en el directorio montado, pero ya no se pueden modificar ni eliminar.

enlaces: CurlFtpFS , ProFTPD

— nrc
fuente

Entiendo lo que estás diciendo, y ciertamente parece ser una opción. Pero si soy el administrador del servidor de archivos, puedo eliminar cualquier cosa. El objetivo es evitar que incluso los administradores (al menos aquellos sin acceso a las unidades físicas) eliminen archivos.

— phil_ayres

El servidor FTP actúa como un dispositivo WORM barato. Pero sí, el administrador del servidor FTP remoto puede acceder a los archivos y modificarlos. Una solución es firmar el archivo en su creación, con un sistema de clave asimétrica, para evitar que cualquier administrador del sistema pueda meterse con los archivos. Un administrador aún puede borrar los archivos pero no puede modificar más el archivo sin ser notado.

— nrc

Desafortunadamente, solo firmar el archivo para demostrar (falta de) manipulación no es suficiente de acuerdo con las normas de la SEC. De ahí la pregunta sobre cómo hacer que los archivos sean completamente inmutables.

— phil_ayres

0

Esta es una variación del problema de " Copia de seguridad infalible " y la única forma de implementarlo es con múltiples sistemas de archivos de gusanos remotos que usan y comparten sumas de verificación y no tienen acceso físico o de administración compartido. Esto garantiza que todo se escriba una vez, se duplique, se pueda comprobar la integridad y, en el caso de que se borre, modifique o corrompa un solo bloque, se pueda recuperar.

Plan9 o sus derivados pueden implicar todas las características requeridas. Ver Plan9 y Venti

— Daniel Matthews
fuente