> Hoy entr� en una m�quina a la que ten�a acceso f�sico
> simplemente arrancando con un floppy, buscando a la brava el
> /etc/shadow y cambiando la contrase�a de root. No pude montarlo por
> alguna extra�a raz�n (quiz� porque el mount del floppy es una
> versi�n demasiado antigua).
>
> Como no me apetece que nadie me haga lo mismo ;^) estaba
> mirando alguna forma de encriptar el disco. Empec� mirando sistemas
> de archivos encriptados y la cosa me convence pero se da la
> casualidad de que /etc/shadow est� y debe estar en la partici�n
> ra�z, que es m�s liosa de encriptar. Por tanto una soluci�n
> orientada a archivos particulares me viene mejor pero quiero que
> sea de forma transparente, es decir, en el n�cleo. Supongo que el
> candidato id�neo para esto es chattr pero de momento parece que a
> (...)
No lo hagas.
Primero que nada: Conceptos b�sicos de seguridad. Lo primero a tomar en
cuenta es la SEGURIDAD F�SICA de tu equipo.
Si alguien tiene acceso f�sico a tu m�quina, hay poco que puedas hacer
para evitar que haga lo que quiera. S�, puede arrancar de floppy. Puede
arrancar en modo monousuario. �Y si tienes tu disco duro cifrado y el LILO
protegido? Bueno, puede arrancar de floppy copiando -aunque sea por ensayo
y error- los par�metros de tu lilo.conf. Si realmente le importa, lo
conseguir�. Y si no as�, de alg�n modo descifrar� tu partici�n. O
levantar� tu m�quina y le explotar� alg�n servicio vulnerable. Nunca
podr�s tener una m�quina segura si personas hostiles tienen acceso f�sico
a ella.
Segundo: �Por qu� no usar un sistema de archivos cifrado? Bueno...
Sencillo. Tu sistema de archivos es lo m�s importante que tiene tu
computadora. Toda tu informaci�n est� ah�. Y si usa un buen algoritmo de
cifrado, cualquier error -por m�s que sea de un s�lo bit- va a hacer
imposible la recuperaci�n de tu informaci�n. Los discos duros son
falibles, aunque poco... �Quieres arriesgarte a perder todo de golpe?
Y tercero: Respecto al cifrado autom�tico de cada archivo - Cito de la
p�gina de manual chattr(1):
A file with the `c' attribute set is automatically com�
pressed on the disk by the kernel. A read from this file
returns uncompressed data. A write to this file compresses
data before storing them on the disk.
Pero m�s abajo:
BUGS AND LIMITATIONS
As of Linux 2.2, the `c', 's', and `u' attribute are not
honored by the kernel filesystem code. These attributes
will be implemented in a future ext2 fs version.
O sea, la compresi�n autom�tica es una buena idea... Pero no est�
implementada, pues es demasiado complejo asegurarse de que un kernel lo
haga bien. M�s a�n ha de ser el cifrado. Adem�s, un cifrado de nada te
sirve si no es el usuario quien mete -cada que descifres el archivo- la
llave para descifrarlo... Si es algo que el sistema puede hacer
autom�ticamente, cualquier atacante con dos dedos de frente podr� tambi�n
hacerlo.
Moraleja: Seguridad f�sica por sobre todo.
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118