|
|
|
Secciones
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Capa de invisibilidad para sistema de ficheros...
|
Log in/Crear cuenta
| Top
| 25 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
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).