11:48h.
Dandole vueltas a lo que decia el otro dia sobre un sistema de ficheros que permitiese una capa de invisibilidad de directorios para facilitar la tarea a los que comienzan en esto de la informatica y que tienen a un BOFH cerca.(lease nuestros padres y madres mayores ellos ya :P)
Voy a plasmar un pequeño esquema de como deberia funcionar este sistema de invisibilidad desde el punto de vista de una aplicación por encima del ls, rogando que si alguien lo implementa me cite en sus creditos.
Suponiendo que el aplicativo se llama hiddendir
El sistema consta de 2 ficheros importantes:
#fichero que contiene todos los usuarios a los que se le aplica la capa de invisibilidad. /etc/hiddendir/NoAdmins
#carpetas que pueden ver los usuarios que estan arriba. contendrá siempre ~ como directorio visible. /etc/hiddendir/VisibleDirs
Suponiendo que el usuario abre una sesion de consola (o de login) inicialmente estara en ~ (/home/Usuario) en principio y asi por encima podemos ver 4 operaciones basicas en las que el software se pondrá por delante de las operaciones normales.
Crear un directorio
Borrar un directorio
Visualizar un directorio
Crear un enlace simbolico
La operacion mover y copiar se pueden equiparar a las operaciones simples borrar y crear un directorio y a crear un directorio respectivamente.
Analicemos cuales seran los pasos para Crear un directorio.Es equivalente a crear un enlace simbolico a un directorio, debiera de realizarse los mismos pasos.
Inicialmente estamos en /home/Usuario
usuario ejecuta mkdir.invisible /Prueba
el programa busca en la lista de NoAdmins al usuario
-si está ejecuta el verdadero mkdir /Prueba (que ya se encargará de permisos y cosas asi), y si todo ha ido correctamente añade la ruta a la lista de directorios visibles sin preguntar.
-si no está en la lista Pregunta al admin si quiere hacerlo visible a los usuarios si contesta que si ejecuta el verdadero mkdir /Prueba y añade a la lista de directorios visibles el directorio si mkdir devuelve que todo ha ido bien y si contesta que no, simplemente ejecuta mkdir /Prueba.
Ahora probemos con Borrar.
usuario ejecuta rmdir.invisible /Prueba
el programa busca en la lista de directorios visibles el directorio a borrar y si está entonces ejecuta rmdir /Prueba y luego si ha ido bien borra la entrada del fichero VisibleDirs.
Por ultimo Mostrar directorio, este es el mas complicado.
usuario ejecuta ls.invisible /Prueba
Si el usuario no esta en la lista de NoAdmins, hace un ls /Prueba
Si el usuario esta en la lista de NoAdmins.
Si la carpeta /Prueba no esta en la lista de VisibleDirs entonces muestra mensaje de advertencia y muestra la carpeta ~ (/home/Usuario)
Si la carpeta /Prueba esta en la lista de VisibleDirs entonces coge todas las subcarpetas de /Prueba que esten en la lista VisibleDirs y la almacena en una variable, luego hace un ls /Prueba en el que solo muestre ficheros no directorio y la salida la concatena con un ls /Prueba de ficheros directorio al que se le pasa un grep de la variable que habiamos almacenado. de este modo mostrará todos los ficheros de esa carpeta y solo las subcarpetas que corresponda.
Soy consciente que le queda muxo por pulir, asi a bote pronto, veo posibles fallos si por casualidad a alguien se le ocurre hacer un ls -r o algo asi, o un ls -l o mil cosas asi, pero es cuestion de ir depurandolo.
Tambien he de explicar que esto realmente le veo sentido para los exploradores graficos(lease el gnome, kde, etc), de esta manera si tu haces que funcione para konqueror, el usuario si por casualidad el openoffice lo enviase a /usr/share/openoffice.org/icons si no hay un enlace simbolico a esta carpeta que tenga permiso de visualizacion entonces no se mostraria e iria a /home/Usuario y claro el usuario tendria siempre las cosas ordenadas.
Bueno quien haya leido hasta aqui muchisimas gracias porque reconozco que es una paja mental impresionante pero es que necesitaba escribirlo porque si al final nadie se pone a implementarlo igual me pongo yo que le veo su gracia.
El unico problema que veo es como hacer que gnome, kde, etc muestren solo los directorios que yo quiero.Que me parece que no va a ser tan sencillo como crear ficheros.invisible :P
Ah el objetivo de todo esto es que el usuario no vea las carpetas que no queremos que vea pero que si que puedan ejecutar, leer y escribir los programas que use en las carpetas que tenga permiso. Vamos que no es una accion de seguridad sino mas bien una accion de generar sensacion de tranquilidad al usuario sintiendo que su sistema no es tan complicado. En el fondo es como cuando windows pone su ocultar ficheros del sistema pero a lo bestia es decir que el usuario tuviese la sensacion de que el sistema es su home y su menu aplicaciones.
Verde
(Puntos:2)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Igual te interesa leerte el capitulo del Tannenbaum de sistemas operativos que habla de usuarios/permisos/recursos.
Si no te quieres comer mucho la cabeza, la forma habitual, lenta y facil es con bosques (conjuntos de arboles) al estilo de lo que se suele hacer en las empresas con LDAP.
En España la mejor manera de guardar un secreto es escribir un libro.
Hombre
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Miércoles, 17 Agosto de 2005, 18:26h )
Extended attributes are name:value pairs associated with inodes by
the kernel or by users (see the attr(5) manual page, or visit
http://acl.bestbits.at/ [bestbits.at] for details).
La opción más sencilla seria modificar el driver de ext3 para que, cuando se intente acceder a un directorio, actue como que este no existe si el directorio está oculto (tiene un atributo oculto=1) y el usuario que realiza la acción sobre el directorio no es su propietario. También se podrian hacer cosas más complicadas si lo mezclas con ACL.
El único problema es que esto solo funcionaria en ext3. Aunque por poder se puede modificar cualquier sistema de ficheros para hacer algo semejante.
Otra opción a nivel de usuario es crear una libreria que haga de "wrapper" entre los programas y opendir()&friends... bueno tu verás cual te hace más gracia.
LKM
(Puntos:2, Informativo)( http://barrapunto.com/ | Última bitácora: Domingo, 14 Febrero de 2010, 23:49h )
Haz que los ficheros que empiecen por el prefijo que tú quieras solo sean visibles si tienes un UID XXX, donde XXX sea tu UID (102, 1002, etc..).
Podrías pasarle los prefijos/sufijos de los ficheros y el UID del usuario que si puede ver dichos ficheros al módulo como un parámetro de línea de comandos para cuando carga el módulo, algo así como:
int myuid;
char *mystring;
MODULE_PARM (myuid, "i");
MODULE_PARM (prefix, "s");
Este módulo no es difícil de hacer. Para un kernel 2.4 con que cambies la entrada de la sys_call_table correspondiente a open (sys_call_table[__NR_open]) y la sustituyas por la tuya basta, si bien es la ostia de peligroso...
Para un kernel 2.6 puedes utilizar Kernel Hooks( Te recomiendo que eches un vistazo a http://www.phrack.org/show.php?p=58&a=8 y http://www.phrack.org/show.php?p=58&a=7) o Kernel Probes que viene integrado en la rama genérica del kernel Linux). Para utilizar kernel probes tienes que tener un kernel que lo soporte. Para ello cuando hagas el "make menuconfig" vete a "Kernel Hacking" y busca "Kprobes".
Bueno, espero haberte ayudado.
FreeBatasuna [blogspot.com].
y qué tal un MAC¿?
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Lunes, 21 Junio de 2010, 05:00h )
Un resumen de la toma de decisiones del modelo sería este:
- Se garantiza acceso si el nivel del sujeto es superior o domina al objeto (ss-property).
- Si el acceso requerido es de escritura no se concede a no ser que los niveles de sujeto y objeto sean iguales (*-property).
- El tipo de acceso debe estar presente en la matriz de permisos, si no está presente el tipo de acceso no se concede aunque el nivel del usuario/sujeto sea mayor que el del objeto (ds-property).
Para concederse debe pasar las tres propiedades, si una no la concede el acceso es denegado.
Y si lo que te interesa es monitorizar llamadas al sistema con rsbac puedes (también implementa el modelo de Bell y la Pádula).