parche kernel ext4

[Alejandro Vargas]

Tengo una situación rara, como de costumbre:

Estoy preparando un sistema con una raspberry pi y quisiera enredar un poco
el filesystem principalmente para tener una mínima seguridad de que no será
trivial toquetear las cosas con sólo enchufar la tarjeta en una PC.

Se me ocurría que tal vez podría agregar unas pocas instrucciones al kernel
para hacer por ejemplo un XOR con un valor fijo a los datos antes de
grabarlos y después de leerlos del disco. Se que no es una gran seguridad
pero al menos es un obstáculo.

La pregunta es: tienen idea de en qué parte debería meter el parche? Qué
funciones usan los drivers del kernel para leer o escribir datos en el
disco? Me conviene toquetear el ext4 o tal vez más abajo la lectura y
escritura de la tarjeta SD?

[Edgardo]

Hola alejandro, no se que sera un raspberry pi, pero podrias probar
encriuptando el filesystem!


El 17 de diciembre de 2012 07:16, Alejandro Vargas

Post by Alejandro Vargas
Estoy preparando un sistema con una raspberry pi y quisiera enredar un poco
el filesystem principalmente para tener una mínima seguridad de que no será
trivial toquetear las cosas con sólo enchufar la tarjeta en una PC.
Se me ocurría que tal vez podría agregar unas pocas instrucciones al kernel
para hacer por ejemplo un XOR con un valor fijo a los datos antes de
grabarlos y después de leerlos del disco. Se que no es una gran seguridad
pero al menos es un obstáculo.
La pregunta es: tienen idea de en qué parte debería meter el parche? Qué
funciones usan los drivers del kernel para leer o escribir datos en el
disco? Me conviene toquetear el ext4 o tal vez más abajo la lectura y
escritura de la tarjeta SD?
--
Qapla'
Alejandro Vargas

[Sefer]

 
https://es.wikipedia.org/wiki/Raspberry_pi
Saludos. Sefer.

----- Mensaje original -----
De: Edgardo <***@gmail.com>
Para: lug-***@lugmen.org.ar
CC:
Enviado: Martes, 18 de diciembre, 2012 2:02 P.M.
Asunto: Re: parche kernel ext4

Hola alejandro, no se que sera un raspberry pi, pero podrias probar
encriuptando el filesystem!


El 17 de diciembre de 2012 07:16, Alejandro Vargas

Post by Alejandro Vargas
Estoy preparando un sistema con una raspberry pi y quisiera enredar un poco
el filesystem principalmente para tener una mínima seguridad de que no será
trivial toquetear las cosas con sólo enchufar la tarjeta en una PC.
Se me ocurría que tal vez podría agregar unas pocas instrucciones al kernel
para hacer por ejemplo un XOR con un valor fijo a los datos antes de
grabarlos y después de leerlos del disco. Se que no es una gran seguridad
pero al menos es un obstáculo.
La pregunta es: tienen idea de en qué parte debería meter el parche? Qué
funciones usan los drivers del kernel para leer o escribir datos en el
disco? Me conviene toquetear el ext4 o tal vez más abajo la lectura y
escritura de la tarjeta SD?
--
Qapla'
Alejandro Vargas

[Alejandro Vargas]

Post by Edgardo
Hola alejandro, no se que sera un raspberry pi,

Una placa del tamaño de la palma de la mano, que tiene un procesador
broadcom de 800Mhz, 512 Mb de RAM, 2 puertos USB, salida de sonido, video
compuesto y HDMI. El sistema operativo se pone en una tarjeta SD. Se
alimenta con 5V y tiene varios pines de uso general para conectar
dispositivos electrónicos. Todo eso por unos 25 dólares más gastos de envío.

Post by Edgardo
pero podrias probar
encriuptando el filesystem!

Esa es la idea pero tengo dos ... bueno, tres requisitos:

1) El root filesystem tiene que estar encriptado/ofuscado mínimamente. No
es necesaria una alta seguridad aunque no estaría de más.
2) No puede haber interacción con el usuario. Es un dispositivo embebido
así que no se puede esperar que haya una persona tecleando una clave al
arrancar.
3) No puede usar initrd (que yo sepa el bootloader de la raspberry no lo
soporta)

Mi idea era hacer algo sencillo: agarrar el fuente del ext4fs, buscar en
qué lugar hace las lecturas y escrituras en el dispositivo de bloques (el
disco físico), y agregar un simple for para recorrer el buffer haciendo por
ejemplo xor con un valor fijo, o una rotación de bits o algo así.

La idea es que como es un dispositivo embebido, no quiero que nadie saque
la tarjeta, la ponga en una PC y se ponga a hurgar en ella. Si es alguien
con los conocimientos suficientes para deducir una encriptación sencilla,
entonces puedo confiar en que también tendrá los conocimientos suficientes
para no hacer desastres con el sistema. A no ser, claro, que lo haga
intencionalmente. En cuyo caso no veo forma de evitarlo así que me
concentro en lo que puedo hacer.

[Yordanis Castillo]

necesito saber como puedo cambiar la clabe publica a mi repo

[MAbeeTT]

Post by Alejandro Vargas

Post by Edgardo
Hola alejandro, no se que sera un raspberry pi,

Una placa del tamaño de la palma de la mano, que tiene un procesador
broadcom de 800Mhz, 512 Mb de RAM, 2 puertos USB, salida de sonido, video
compuesto y HDMI. El sistema operativo se pone en una tarjeta SD. Se
alimenta con 5V y tiene varios pines de uso general para conectar
dispositivos electrónicos. Todo eso por unos 25 dólares más gastos de envío.

Post by Edgardo
pero podrias probar
encriuptando el filesystem!

1) El root filesystem tiene que estar encriptado/ofuscado mínimamente. No
es necesaria una alta seguridad aunque no estaría de más.
2) No puede haber interacción con el usuario. Es un dispositivo embebido
así que no se puede esperar que haya una persona tecleando una clave al
arrancar.
3) No puede usar initrd (que yo sepa el bootloader de la raspberry no lo
soporta)
Mi idea era hacer algo sencillo: agarrar el fuente del ext4fs, buscar en

Yo atacaría por el lado de VFS, que todos los sistemas de archivos
pasan por ahí. Si eventualmente cambiás de sistema de archivos el
cambio seguirá siendo útil.
Cualquiera de las cosas que implementés pensá bien qué pasaría si en
tu conversión terminás escribiendo una "secuencia de escape" que
después fuerce un chequeo en un sistema regular y potenciales
recuperaciones de archivos que romperán todo.

(mi experiencia fue que hice un badblocks con lectura y escritura, lo
detuve porque llebaba mucho tiempo, particioné, formateé y luego
aparecienron miles de miles de archivos porque uno de los algoritmos
escribía la secuencia de fin de archivo, o inicio, no sé, el problema
persistía con formateos "completos" o "lentos" )

Post by Alejandro Vargas
qué lugar hace las lecturas y escrituras en el dispositivo de bloques (el
disco físico), y agregar un simple for para recorrer el buffer haciendo por
ejemplo xor con un valor fijo, o una rotación de bits o algo así.

Por otro lado el procesador que tiene es lo suficientemente poderoso
como para poder cifrar con algún mecanismo parecido a tus XORs muy
económicas en CPU. Podrías enviar la llave por línea de comando de
kernel, haría que estudiar al bootloader.

Post by Alejandro Vargas
La idea es que como es un dispositivo embebido, no quiero que nadie saque
la tarjeta, la ponga en una PC y se ponga a hurgar en ella. Si es alguien
con los conocimientos suficientes para deducir una encriptación sencilla,
entonces puedo confiar en que también tendrá los conocimientos suficientes
para no hacer desastres con el sistema. A no ser, claro, que lo haga
intencionalmente. En cuyo caso no veo forma de evitarlo así que me
concentro en lo que puedo hacer.
--
Qapla'
Alejandro Vargas

--
.::MAbeeTT::.

mabeett [at] gmail [ dot] com

[Alejandro Vargas]

Post by MAbeeTT
Yo atacaría por el lado de VFS, que todos los sistemas de archivos
pasan por ahí. Si eventualmente cambiás de sistema de archivos el
cambio seguirá siendo útil.
Cualquiera de las cosas que implementés pensá bien qué pasaría si en
tu conversión terminás escribiendo una "secuencia de escape" que
después fuerce un chequeo en un sistema regular y potenciales
recuperaciones de archivos que romperán todo.

No tiene por qué romperse nada...

A ver, yo lo veo fácil todo filesystem tarde o temprano tiene que leer o
escribir cosas en el disco físico. En ese momento se puede hacer cualquier
operación con los datos leídos y escritos mientras se haga y se deshaga lo
mismo. Cualqueir chequeo que se haga tiene que pasar también por ese mismo
proceso así que debería ser transparente.

Por ejemplo, cuando se encripta mediante loop por ejemplo, lo que se hace
es crear un dispositivo que en definitiva lee y escribe del disco, pero
pasa previamente por el driver del loopback que hace una operación con los
datos (por ejemplo un xor), por ejemplo:

losetup -e xor /dev/loop0 /dev/sda1

Esto por ejemplo haría de filtro entre el loop0 y el sda1, pero haría un
xor a todos los datos que pasen. El filesystem en loop0 se puede montar,
chequear, o todo lo que te de la gana.

Lo que yo quisiera hacer es lo mismo que hace el losetup pero metido dentro
del kernel porque quiero evitar el uso de una initrc que haga esto.

Post by MAbeeTT

Post by Alejandro Vargas
qué lugar hace las lecturas y escrituras en el dispositivo de bloques (el
disco físico), y agregar un simple for para recorrer el buffer haciendo

por

Post by Alejandro Vargas
ejemplo xor con un valor fijo, o una rotación de bits o algo así.

Por otro lado el procesador que tiene es lo suficientemente poderoso
como para poder cifrar con algún mecanismo parecido a tus XORs muy
económicas en CPU. Podrías enviar la llave por línea de comando de
kernel, haría que estudiar al bootloader.

sí, puedo poner algo en la línea de comando del kernel, pero todavía tengo
el problema de cómo hacer el "encriptado/ofuscado"... Si es un parche, no
necesito pasar una clave porque lo puedo meter en el mismo kernel.

Al final tal vez tenga que investigar cómo hacer una initrd. Me parece
haber leído que se puede meter la initrd dentro del mismo kernel. Eso
seguramente funcionaría. Si es así, hago un losetup y listo.

[MAbeeTT]

qué pasaría si en

Post by Alejandro Vargas

Post by MAbeeTT
tu conversión terminás escribiendo una "secuencia de escape" que
después fuerce un chequeo

en un sistema regular y potenciales

Post by Alejandro Vargas

Post by MAbeeTT
recuperaciones de archivos que romperán todo.

Regular en tanto que ordinario.

Post by Alejandro Vargas
No tiene por qué romperse nada...
A ver, yo lo veo fácil todo filesystem tarde o temprano tiene que leer o
escribir cosas en el disco físico. En ese momento se puede hacer cualquier
operación con los datos leídos y escritos mientras se haga y se deshaga lo
mismo. Cualqueir chequeo que se haga tiene que pasar también por ese mismo
proceso así que debería ser transparente.
Por ejemplo, cuando se encripta mediante loop por ejemplo, lo que se hace
es crear un dispositivo que en definitiva lee y escribe del disco, pero
pasa previamente por el driver del loopback que hace una operación con los
losetup -e xor /dev/loop0 /dev/sda1
Esto por ejemplo haría de filtro entre el loop0 y el sda1, pero haría un
xor a todos los datos que pasen. El filesystem en loop0 se puede montar,
chequear, o todo lo que te de la gana.
Lo que yo quisiera hacer es lo mismo que hace el losetup pero metido dentro
del kernel porque quiero evitar el uso de una initrc que haga esto.

Si sacás la tarjeta, la ponés en una computadora común puede pasar lo
que dije más arriba.

Post by Alejandro Vargas

Post by MAbeeTT

Post by Alejandro Vargas
qué lugar hace las lecturas y escrituras en el dispositivo de bloques (el
disco físico), y agregar un simple for para recorrer el buffer haciendo

por

Post by Alejandro Vargas
ejemplo xor con un valor fijo, o una rotación de bits o algo así.

Por otro lado el procesador que tiene es lo suficientemente poderoso
como para poder cifrar con algún mecanismo parecido a tus XORs muy
económicas en CPU. Podrías enviar la llave por línea de comando de
kernel, haría que estudiar al bootloader.

sí, puedo poner algo en la línea de comando del kernel, pero todavía tengo
el problema de cómo hacer el "encriptado/ofuscado"... Si es un parche, no
necesito pasar una clave porque lo puedo meter en el mismo kernel.

Podés compilar el kernel harcodeando los argumentos que recibe, hay un
ajuste en el menuconfig de ignorar al bootloader y cargar los
argumentos al momento de compilar.

Post by Alejandro Vargas
Al final tal vez tenga que investigar cómo hacer una initrd. Me parece
haber leído que se puede meter la initrd dentro del mismo kernel. Eso
seguramente funcionaría. Si es así, hago un losetup y listo.

Me sigue pareciendo más sencillo los parámetros de kernel.


--
.::MAbeeTT::.

mabeett [at] gmail [ dot] com

[Alejandro Vargas]

Post by Alejandro Vargas

Post by Alejandro Vargas
Lo que yo quisiera hacer es lo mismo que hace el losetup pero metido

dentro

Post by Alejandro Vargas
del kernel porque quiero evitar el uso de una initrc que haga esto.

Si sacás la tarjeta, la ponés en una computadora común puede pasar lo
que dije más arriba.

Ahh!, sí, eso sí es cierto. Pero bueno, te pasa con cualquier partición
encriptada que tengas.

Post by Alejandro Vargas
sí, puedo poner algo en la línea de comando del kernel, pero todavía tengo

Post by Alejandro Vargas
el problema de cómo hacer el "encriptado/ofuscado"... Si es un parche, no
necesito pasar una clave porque lo puedo meter en el mismo kernel.

Podés compilar el kernel harcodeando los argumentos que recibe, hay un
ajuste en el menuconfig de ignorar al bootloader y cargar los
argumentos al momento de compilar.

Interesante, lo voy a investigar.

Post by Alejandro Vargas

Post by Alejandro Vargas
Al final tal vez tenga que investigar cómo hacer una initrd. Me parece
haber leído que se puede meter la initrd dentro del mismo kernel. Eso
seguramente funcionaría. Si es así, hago un losetup y listo.

Me sigue pareciendo más sencillo los parámetros de kernel.

Y qué parámetros me servirían para esto? Se puede indicar en parámetros que
monte el disco con un loopback encriptado con una clave fija?

[Rodrigo Campos]

Post by Alejandro Vargas

Post by Alejandro Vargas

Post by Alejandro Vargas
Lo que yo quisiera hacer es lo mismo que hace el losetup pero metido

dentro

Post by Alejandro Vargas
del kernel porque quiero evitar el uso de una initrc que haga esto.

Si sacás la tarjeta, la ponés en una computadora común puede pasar lo
que dije más arriba.

Ahh!, sí, eso sí es cierto. Pero bueno, te pasa con cualquier partición
encriptada que tengas.

Si entiendo bien, no. Porque se da cuenta y lo maneja bien. En lo que vos decís,
no tiene forma de darse cuenta, y si corrige algo (lo corregiría sin tu
"parche", salvo que tengas las herramientas de recuperacion tuneadas también) en
vez de arreglar sigue todo roto cuando bootees con tu kernel.




Saludos,
Rodrigo

[Rodrigo Campos]

Post by Alejandro Vargas
Y qué parámetros me servirían para esto? Se puede indicar en parámetros que
monte el disco con un loopback encriptado con una clave fija?

Capaz lo que querés es usar dm-crypt con un keyfile ?




Saludos,
Rodrigo

[Alejandro Vargas]

Post by Rodrigo Campos

Post by Alejandro Vargas
Y qué parámetros me servirían para esto? Se puede indicar en parámetros que
monte el disco con un loopback encriptado con una clave fija?

Capaz lo que querés es usar dm-crypt con un keyfile ?

Cualquier cosa que no sea trivial descubrir me sirve.

[PaBluK]

Post by Rodrigo Campos

Post by Alejandro Vargas
Y qué parámetros me servirían para esto? Se puede indicar en parámetros

que

Post by Alejandro Vargas
monte el disco con un loopback encriptado con una clave fija?

Capaz lo que querés es usar dm-crypt con un keyfile ?
Si, totalmente de acuerdo con dm-crypt podrias hacerlo sin problemas.

Fijate en estos links
https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Storing_the_key_between_MBR_and_1st_partition
https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Using_LUKS_to_Format_Partitions_with_a_Keyfile

Saludos!

[Alejandro Vargas]

Post by PaBluK
Fijate en estos links

https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Storing_the_key_between_MBR_and_1st_partition
https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Using_LUKS_to_Format_Partitions_with_a_Keyfile

Tiene buena pinta, gracias. No sabía que se le podía decir que sacara la
clave de determinados sectores del disco. En cuanto pueda hacer la prueba
les cuento cómo salió.

[MAbeeTT]

Post by Alejandro Vargas

Post by Alejandro Vargas

Post by Alejandro Vargas
Lo que yo quisiera hacer es lo mismo que hace el losetup pero metido

dentro

Post by Alejandro Vargas
del kernel porque quiero evitar el uso de una initrc que haga esto.

Si sacás la tarjeta, la ponés en una computadora común puede pasar lo
que dije más arriba.

Ahh!, sí, eso sí es cierto. Pero bueno, te pasa con cualquier partición
encriptada que tengas.

No sé.. si yo diseñara algún esquema de encriptación escaparía esos
caracteres... Por ahí ni se gastan, desconozco, estoy muy muy lejos de
ser un indóneo, imaginate.

Post by Alejandro Vargas

Post by Alejandro Vargas
sí, puedo poner algo en la línea de comando del kernel, pero todavía tengo

Post by Alejandro Vargas
el problema de cómo hacer el "encriptado/ofuscado"... Si es un parche, no
necesito pasar una clave porque lo puedo meter en el mismo kernel.

Podés compilar el kernel harcodeando los argumentos que recibe, hay un
ajuste en el menuconfig de ignorar al bootloader y cargar los
argumentos al momento de compilar.

Interesante, lo voy a investigar.

Contanos que sale de esto!!!

Post by Alejandro Vargas

Post by Alejandro Vargas

Post by Alejandro Vargas
Al final tal vez tenga que investigar cómo hacer una initrd. Me parece
haber leído que se puede meter la initrd dentro del mismo kernel. Eso
seguramente funcionaría. Si es así, hago un losetup y listo.

Me sigue pareciendo más sencillo los parámetros de kernel.

Y qué parámetros me servirían para esto? Se puede indicar en parámetros que
monte el disco con un loopback encriptado con una clave fija?

Podés poner lo que se te de la gana, si algo no entiende el kernel, lo
ignora. Hasta podés poner un parser de eso en el sistema de archivos,
en este caso no aplica, obvio.




--
.::MAbeeTT::.

mabeett [at] gmail [ dot] com