Re: Bug #358651, ¿es un problema de seguridad?
Hola, buenas tardes,
Ahondando en lo que dice Javier, un paquete interesante es (yo uso
Etch):
loop-aes-modules-2.6.18-3-686
(o el que corresponda para nuestra versión del núcleo).
Básicamente se trata de un módulo para el núcleo que te permite cifrar
una partición entera. Yo lo he probado y parece que funciona:
Un ejemplo:
1) (Instalamos el mencionado paquete, y "pwgen" y "gnupg" si no los
tenemos)
2) Creamos un fichero que almacenará un "filesystem" de pega (de 100MB,
para probar):
# dd if=/dev/zero of=/mnt/testfs bs=1k count=102400
3) Creamos un fichero (cifrado con gnupg) de contraseñas para acceder al
"filesystem" cifrado:
# pwgen -cns 30 65 | gpg -aco /mnt/testkey
(Nos pedirá introducir una clave, que utilizaremos para acceder al
"filesystem" cifrado)
4) Asociamos un "loop device" con nuestro fichero de "filesystem" y
establecemos el tipo de encriptación para ese "filesystem":
# losetup -e AES256 -K testkey /dev/loop0 testfs
5) Creamos la estructura del "filesystem":
# mkfs -t ext3 /dev/loop0
6) Creamos el directorio de montaje:
# mkdir /mnt/test
7) Deshacemos la asociación entre el "loop device" /dev/loop0 y nuestro
"filesystem" de prueba.
# losetup -d /dev/loop0
8) Añadimos a nuestro fstab una entrada como la siguiente:
/mnt/testfs /mnt/test ext3
defaults,rw,user,noauto,loop=/dev/loop0,encryption=AES256,gpgkey=/mnt/testkey 0 0
9) Ahora, en teoría podemos montar nuestro "filesystem" (sistema de
ficheros) cifrado, incluso como usuario normal:
$ mount /mnt/testfs
Nos pedirá la contraseña que habíamos introducido antes, volverá a
establecer la asociación entre el "loop device" y el sistema de
ficheros, y podremos acceder a este último.
Para poner a buen recaudo el sistema de ficheros, lo desmontamos,
obviamente.
Según la documentación del mencionado paquete, se puede cifrar la
partición raíz entera, de forma que el "problema de seguridad" que nos
ocupa se mitiga un poco, incluso aunque se lleven el disco duro ;)
Un saludo,
Daniel R.
El mar, 30-01-2007 a las 13:11 +0100, Javier Fernández-Sanguino Peña
escribió:
> On Fri, Jan 26, 2007 at 03:13:33PM -0400, José Parrella wrote:
> >
> > Sí es un problema de seguridad. No tener una contraseña configurada para
> > el arranque en Grub no es una buena idea. Alguien puede pasar un
> > parámetro de arranque particular a un kernel y obtener privilegios de
> > superusuario si tiene acceso físico al equipo. Estos problemas se suelen
> > minimizar en un desktop de uso personal, y en las laptops que
> > implementan contraseña para acceder a los discos duros.
>
> Si alguien tiene acceso físico al equipo puede:
>
> a) acceder a la BIOS y cambiar el mecanismo de arranque (de nuevo, debería
> estar con contraseña)
>
> b) abrir el equipo, resetear la BIOS (si la tiene) y cambiar el mecanismo de
> arranque (por tanto, debería estar cerrada la caja con llave)
>
> c) meter una variación de tensión en la fuente suficiente que fuerce a la
> BIOS a resetearse y cambiar el mecanismo de arranque (si la caja está cerrada
> con llave)
>
> d) romper la cerradura, abrir el equipo, llevarse el disco duro a casa y
> mirar sus contenidos (por tanto, deberías tener guardas vigilando que no lo
> hagan o implementar cifrado de discos)
>
> Vamos, que si alguien tiene acceso físico al equipo hay muchas formas (y más
> sencillas) de hacerse con el equipo que utilizar el gestor de arranque (sea
> grub o lilo o el que sea)
>
> Hay que poner las cosas en perspectiva (y no es que me oponga a que se
> cambien los permisos de grub, ni mucho menos)
>
> Un saludo
>
> Javier
Reply to: