Los procedimientos de seguridad deben reducir al mínimo los privilegios, para reducir el error en la posibilidad de fallas de seguridad. Este artículo describe cómo reducir al mínimo los módulos privilegiada, los privilegios concedidos el privilegio, y reducir al mínimo el tiempo efectivo de privilegio.
El artículo no sólo se analizan algunas de las tradicionales clases UNIX privilegiada de mecanismos, también discutieron los mecanismos relativamente nuevos, como la cárcel de FreeBSD (), Linux Security Module (Linux Security Modules, LSM) Marco, y el Linux Security-Enhanced (SELinux).
03 de marzo 2003, Internet Security Systems de Sendmail es un serio defecto en una advertencia. Todos los e-mail a través del agente de transferencia de mensajes (agente de transferencia de correo, MTA) para la transferencia, Sendmail es el más popular MTA, por lo que esta advertencia afectadas muchas organizaciones en todo el mundo. El problema es, según la configuración de costumbre, con sumo cuidado el "de", "a" o "cc" campo de mensajes de correo electrónico permite al remitente completo (root) el control de cualquier máquina de correr un Sendmail. Más grave aún, el servidor de seguridad en general no protege frente a este tipo de ataques dentro de la máquina.
La causa directa de esta laguna, ya que, Sendmail tiene la detección de fallas de seguridad, de desbordamiento de búfer puede ocurrir. Sin embargo, un papel importante en el factor, Sendmail menudo se instala como un solo "setuid root" del programa, ejecutarlo en el sistema tiene permisos de control total. Esto, Sendmail falla en cualquiera de los que puede permitir a un atacante el control directo de todo el sistema.
Este diseño es necesaria? No, Postfix Wietse Venema es un común puede igualar es MTA. Al igual que Sendmail, Postfix hacer un montón de pruebas de seguridad, sin embargo, con el fin de reducir al mínimo los privilegios, Postfix diseñado como un conjunto de módulos. Los resultados, Postfix es generalmente considerado más seguro que el programa Sendmail. Este artículo describe cómo reducir al mínimo los privilegios, puede aplicar la misma idea, a su programa.
Minimizar la base de privilegios
Aplicación práctica de los procedimientos de sus puntos débiles. ¿Queremos realmente, pero realmente lo es. necesidades complejas, las presiones horario y los cambios en el ambiente es poco práctico proceso para impecable. Incluso aquellos que han pasado compleja y sofisticada tecnología para probar formalmente el procedimiento correcto, no habrá fallas. ¿Por qué? Una de las razones es que la verificación se debe realizar una serie de suposiciones, ya menudo estas suposiciones no son del todo correctas. En cualquier caso, por diversas razones, la mayoría de los procedimientos no había sido una prueba rigurosa. Por otra parte, incluso en la actualidad no hay ningún defecto (poco probable), el mantenimiento futuro del cambio o cambios en el ambiente son propensos a introducir defectos. Por lo tanto, para hacer frente a problemas prácticos, nos queda mucho camino para desarrollar los procedimientos de seguridad, a pesar de los defectos de nuestro programa.
A pesar de estas deficiencias, el programa de seguridad es la forma más importante es reducir al mínimo el privilegio. Privilegio no sólo permiten que todos pueden hacer. sistemas UNIX en la clase, con "root" de usuario, otros usuarios o miembros de un grupo de privilegios es el tipo más común de los privilegios. Algunos sistemas permiten la concesión de privilegios de lectura o escritura de archivos específicos. Pero de todos modos, para reducir al mínimo los privilegios:
Sólo una parte del programa necesita los privilegios otorgados y los privilegios
Sólo una parte de ella es absolutamente necesario conceder privilegios específicos
Los privilegios del tiempo efectivo o puede ser restringida efectivamente a la hora mínimo absoluto
El hecho es el objetivo, no absoluta. La base de su organización (tales como su sistema operativo o la máquina virtual) puede hacer que la finalización de estas directivas no es fácil, o del cumplimiento estricto de estos puede ser muy complicada, lo que llevó a la realización del defecto de tratar de introducir más estrictas. Sin embargo, el más cerca de esos objetivos, la posibilidad de defectos conducen a una menor seguridad. Incluso si el defecto había problemas de seguridad, lo que llevó al problema de seguridad podría ser incluso menor. Y si puede asegurarse de que sólo una pequeña parte del programa tiene privilegios específicos, puede utilizar una gran cantidad de tiempo extra para asegurar que una parte que puede soportar los ataques. Esta idea no es nueva; Saltzer y excelente papel de Schroeder 1975 examinó los principios de seguridad, de manera explícita como un principio de privilegio mínimo (ver Recursos). Algunas ideas son eternas, como minimizar el privilegio.
Las tres secciones siguientes se discuten estos objetivos, a su vez, incluyendo la forma de lograr su clase de sistemas UNIX. Entonces, vamos a discutir el FreeBSD y Linux en algunos de los mecanismos especiales disponibles, incluyendo seguridad mejorada de la NSA Linux (SELinux) discusión.
Minimizar privilegiada módulos
Como se mencionó anteriormente, sólo para ser parte privilegiada del programa sólo se aplica privilegiada. Es decir, al diseñar su programa, trate de proceso de dividirse en partes separadas, para que sólo una pequeña parte e independiente de las necesidades de los privilegios específicos.
Si las distintas partes se debe ejecutar, a continuación, utilizar los procesos del sistema UNIX (no temas). Temas compartir sus privilegios de seguridad, el hilo en cuestión puede interferir con el proceso de todos los otros subprocesos. zona privilegiada de la preparación, en los otros programas, ya que está siendo atacado: un día será! Asegúrese de que una parte privilegiada de las pocas cosas que hacer lo menos posible; funcionalidad restringida son los menos susceptibles de ser utilizados.
Un enfoque común es crear una función muy limitada tiene privilegios específicos (como una herramienta de línea de comandos setuid o setgid). comando passwd de UNIX es un ejemplo, es un privilegio particular, herramientas de línea de comandos para modificar la contraseña (con setuid root), pero que puede hacer es cambiar su contraseña. Entonces, ¿puede solicitar una variedad de herramientas GUI para hacer el cambio real passwd. Si es posible, trate de evitar por completo la creación de programas setuid o setgid, es difícil asegurarse de que está verdaderamente proteger a todas las entradas. Sin embargo, a veces es necesario crear un setuid / setgid programas, por lo que cuando sea necesario, en la medida de lo posible para procesar los más pequeños y más limitados.
Hay muchas otras maneras. Por ejemplo, usted puede tener un privilegio especial de un pequeño "servidor (servidor)" proceso; que el servidor permite que sólo así se solicite, pero sólo confirmó que el solicitante está autorizado a emitir la petición. Otro método común es empezar a usar los privilegios de un programa, el programa deriva entonces que renunciar a todos los privilegios del segundo proceso, el proceso por hacer la mayor parte de la obra.
Tenga cuidado de cómo estos módulos se comunican entre sí. En muchos sistemas UNIX, el valor de línea de comandos y el medio ambiente pueden ser vistos por otros usuarios, por lo que no está en el proceso de envío de datos entre el secreto de una buena manera. Tubería puede ser competente, pero con cuidado para evitar el estancamiento (dos fines, volver a cargar una simple solicitud / protocolo de respuesta puede ser competente).
Minimizar los privilegios concedidos
Para asegurarse de que sólo es necesario otorgar privilegios para hacer el procedimiento - se detienen aquí. UNIX manera principal para obtener privilegios a los que se ejecute como un usuario o grupo. Típicamente, el proceso que los utilicen como un usuario y grupo de correr, pero, "setuid" o "setgid" será que el usuario del programa o privilegios de grupo.
Tristemente, hay alguna manera involuntaria al programa "setuid root" privilegios en los sistemas UNIX-desarrolladores. Los desarrolladores piensan que hacer las cosas por sí mismos a ser "fácil" porque no van en cuenta a fondo de sus procedimientos es una necesidad concreta de ningún privilegio especial. El problema es, ya que la mayoría de estos programas para hacer la clase de sistemas UNIX hacer casi todo, así que cualquier defecto puede convertirse rápidamente en un desastre de seguridad.
No sólo porque es necesario para completar una tarea sencilla para dar todos los privilegios. El procedimiento sólo se puede administrar los privilegios que necesitan. Si puede, a setgid para ejecutarlas, no usar setuid - privilegios setgid menos. Crear un usuario y un grupo (no utilizar la raíz), y utilizarlos de acuerdo a sus necesidades. Para asegurarse de que las pertenecientes a raíz ejecutable por root para escribir, para que otros no pueden modificarlos. Los permisos de archivo conjunto muy estricta - si no es absolutamente necesario, no deje que todo el mundo puede leer o escribir archivos, y utilizar los usuarios y grupos específicos. ¿Puede explicar todos estos juegos pueden ser un ejemplo de "top ten" de los resultados de la práctica estándar. Muchos procedimientos son "games» ", para hacer sólo el programa de juego puede ser modificada" top ten "resultados, y decenas de documentos almacenados en el grupo principal son los juegos (y sólo este grupo puede escribir). Incluso si el ataque atacante y entró en un programa de juego, lo único que podía hacer era modificar las puntuaciones de los documentos. En cualquier caso, los desarrolladores de juegos todavía tienen que escribir sus programas para prevenir la puntuación de archivo malicioso.
chroot () llamada al sistema es una herramienta útil - por desgracia, hay algunas difíciles de usar. Cuando la vista del proceso el sistema de archivos "root", esta llamada al sistema va a modificar el proceso para verificar el contenido. Si usted planea utilizarlo - y puede ser útil - para estar listo para tomar algo de tiempo para hacer un buen uso de ella. Debe ser preparado cuidadosamente "nueva raíz", lo cual es complicado debido a la aplicación exacta depende de la plataforma y las características de la aplicación. Tiene que ser root, que se chroot () de llamada, y pronto debe cambiar el estado de no-raíz (los usuarios de raíz desde el entorno chroot, así que si entra en vigor, es necesario levantar el privilegio). Y chroot no cambiará acceso a la red. Esto puede ser útil un sistema de llamadas, todas las veces es necesario pensar en ello, pero el esfuerzo para hacer bien preparado.
La limitación de recursos es una herramienta a menudo olvidados, que incluye tanto el proceso de recursos de almacenamiento, incluidos los recursos. Estas restricciones de la negación de los ataques del servicio son especialmente útiles:
Al almacenamiento, se pueden establecer para cada usuario o grupo para cada sistema de archivos montado o un archivo el número de contingente de almacenamiento (límite). En GNU / Linux, consulte cuotas (1), quotactl (2) y quotaon (8) comprensión en profundidad de esta característica, sin embargo, cuando a pesar de que no son capaces de utilizar la mayoría de la clase de los sistemas UNIX son el sistema de cuotas. En GNU / Linux y otros sistemas, puede establecer "duras" límites (nunca superior) y "blandas" límites (que puede ser el exceso temporal).
El proceso es, puede establecer límites importantes, tales como el número de archivos abiertos, el número de procesos, y así sucesivamente. Esta capacidad es en realidad parte de la norma (por ejemplo, una sola especificación de UNIX (Single UNIX Specification)), todos ellos en la clase de sistemas UNIX casi ubicua de entender, ver getrlimit (2), setrlimit (2) y getrusage ( 2), sysconf (3) y ulimit (1). Proceso no puede superar nunca la línea "actual", pero pueden límite en todo momento a la altura de la actual "tope". Desafortunadamente, no existe una anomalía problemas plazo puede causar confusión. "La línea actual" es también conocido como "blandas" las fronteras, limitar, también conocido como "duro" límites. De esta forma, usted estará en una situación inusual, el proceso no puede superar los límites del proceso de blando (actual) los límites - y usted puede superar el límite de cuota es suave. Propongo limitar el proceso de utilizar el término "línea actual" y "tope" (no usar nunca el término "suave" y "duras"), así que no habría confundido.
Minimizar el tiempo de privilegio
Pero sólo cuando sea necesario para proporcionar privilegios - no se dé por un momento.
Siempre que sea posible, el uso no importa cuál sea su necesidad inmediata, privilegios, y luego les dan de forma permanente. Una vez que hayan sido definitivamente abandonado, entonces el atacante no puede hacer ningún otro uso de esos privilegios. Por ejemplo, la necesidad de privilegios de root individual a la raíz, el procedimiento se puede iniciar (por ejemplo, a través de un setuid root) y luego cambiar a los usuarios menos privilegiados a correr. Este es el número de servidores de Internet (incluyendo el servidor Web Apache) los métodos utilizados. Clase sistemas UNIX no permiten ningún programa para abrir 0 到 1024 el puerto TCP / IP, debe tener privilegios de root. Pero la mayoría de servidores sólo necesitan tiempo para abrir los puertos de arranque, después de que el privilegio ya no necesita. Una forma es ejecutar como root, tan pronto como sea posible para abrir los puertos necesarios privilegiada, y esta vez permanentemente eliminar los privilegios de root (incluido el proceso pertenece a ningún grupo privilegiado). Va a tratar de eliminar todos los privilegios heredados de otros, por ejemplo, cerrar lo antes posible necesidad de privilegios específicos para abrir el archivo.
Si no puede renunciar de manera permanente los privilegios, entonces usted puede extracción al menos temporal, de los privilegios de la mayor frecuencia posible. Esto es mejor que desprenderse definitivamente de los privilegios, porque si un atacante puede controlar su programa, el atacante puede volver a habilitar el privilegio y usarlo. Sin embargo, vale la pena hacerlo.
Muchos ataques sólo cuando tengan el privilegio de engañar al procedimiento para hacer algunas cosas fuera del programa y los privilegios del programa están habilitadas para tener éxito (por ejemplo, mediante la creación de una anomalía de enlace simbólico y enlaces duros). Si el programa no suele permitir que sus privilegios, el atacante desea tomar ventaja de este programa será más difícil.
Relativamente nuevo mecanismo
Hasta ahora, hemos discutido los principios en realidad se aplican a casi todos los sistemas operativos, y, desde el siglo 19, 70 años, casi todos de la clase de los sistemas UNIX son similares a los mecanismos convencionales. Eso no quiere decir que son inútiles; simple y la prueba del tiempo es su propio beneficio. Sin embargo, algunos de clase relativamente nueva de los sistemas UNIX aumenta hasta al menos el apoyo mecanismo de privilegio, vale la pena conocer. Aunque es fácil de encontrar mecanismo de tiempo de prueba, pero en el mecanismo relativamente nuevo para la información no se conoce todavía. Así que, aquí voy a discutir algún mecanismo valioso seleccionado: la cárcel de FreeBSD (), Linux Security Module (LSM) y el marco de seguridad mejorada de Linux (SELinux).
la cárcel de FreeBSD ()
chroot () llamada al sistema tiene un montón de problemas, como se mencionó anteriormente. Por ejemplo, es difícil de corregir el uso, siendo usuario root puede aprender, pero no el control de acceso de red. desarrolladores de FreeBSD decidió añadir una nueva llamada al sistema para resolver estos problemas, el nuevo sistema denominado llamada cárcel (). Esta llamada es similar al chroot (), pero trate de un uso más fácil y más eficiente de usar. En una cárcel, todas las solicitudes (incluso de root) se limitan la cárcel, la cárcel y en el proceso sólo se puede comunicar con otros procesos, y el sistema bloqueado los intentos del usuario root a la cárcel la forma de los típicos. la cárcel se le asignará una dirección IP específica, no se puede utilizar cualquier otra dirección como su propia dirección.
la cárcel () es única para FreeBSD, lo que limita su utilidad. Sin embargo, todos los sistemas OSS / FS tiene un montón de cruce entre el impacto del núcleo (polinización cruzada). Por ejemplo, utilizando el marco de la seguridad de Linux ha sido desarrollado para la versión Linux de una cárcel. Además, FreeBSD 5 ha añadido un marco flexible MAC (de TrustedBSD proyecto), incluyendo las funciones básicas de un módulo similar a SELinux. Todos, en el futuro para ver más de esta situación no se sorprenda.
Módulo de seguridad de Linux (LSM)
En la Cumbre 2001 del núcleo Linux sobre, Linus Torvalds tiene un problema. Una serie de proyectos de seguridad, incluyendo la seguridad mejorada de Linux (SELinux) del proyecto, para pedirle que añadir sus métodos de seguridad para el kernel Linux. El problema es que estos diferentes métodos son a menudo incompatibles. Torvalds hay una forma simple para determinar cuál es el mejor, por lo que solicitó que el proyecto fue co-crear un marco común de seguridad de Linux. Así, el administrador puede darles cualquier método de instalación especial quieren seguridad. Después de varias conversaciones con Torvalds, Crispin Cowan crear un grupo para crear el marco común de seguridad. Este marco se llama Linux Security Module (LSM) marco, ahora es parte del núcleo estándar de Linux (como la versión 2.6 del kernel).
Conceptualmente, el marco LSM es extremadamente simple. kernel de Linux siguen haciendo su rutina de inspección de seguridad; ejemplo, si escribe un archivo, usted todavía necesita tener acceso de escritura a su.
Sin embargo, siempre que sea necesario si el kernel de Linux deberían permitir el acceso para determinar si debe ser comprobado - por un "libro" a la demanda de un módulo de seguridad para llevar a cabo - para determinar si la acción lo permitan. De esta manera, los administradores pueden simplemente seleccionar que quiere utilizar el módulo de seguridad, así como la pieza del módulo igual que otros kernel de Linux. Desde entonces, el módulo de seguridad determinará lo que está permitido.
LSM marco diseñado para ser tan flexible que puede obtener muchos diferentes tipos de políticas de seguridad. De hecho, un número de diferentes proyectos en conjunto para asegurar que el marco suficiente LSM competente del trabajo real. Por ejemplo, cuando el objeto interno se crea o se eliminan cuando el LSM en un número de llamadas - no se debe a que estas operaciones pueden ser suspendidos, pero para el módulo de seguridad puede llevar un registro de datos importantes. El uso de un número de diferentes herramientas analíticas para garantizar que el marco LSM no se pierde ninguna anomalía importante de su rama de destino. Los resultados muestran que el proyecto de lo que muchos piensan más difícil, y su éxito se consiguen con dificultad.
LSM es necesario entender las decisiones de diseño básico que había hecho. Básicamente, el marco LSM fue diseñado para casi todas las ramas son limitadas excepciones, no es fiable (oficial). Poder para hacer creíble un anormal decisión final absoluta: Si la excepción es la rama que la petición se debe permitir, será permitido sin condiciones. Por el contrario, no puede sino aumentar la credibilidad de la rama anormal de las demás restricciones, no puede conceder nuevos derechos. En teoría, si todas las ramas son creíbles LSM anormal, LSM marco será más flexible. Una llamada puede () rama excepción es seguro - pero sólo porque tenía que apoyar la capacidad de regular POSIX. Sin embargo, la carta puede hacer todas las ramas anormal, es necesario el kernel de Linux, muchos cambios fundamentales, dice que el cambio no puede ser aceptada.
Muchas personas temen que si la mayoría de la rama anormal puede creer, hasta el más mínimo defecto se convertirá en un desastre, y dejar que la excepción es la rama de medios limitados que los usuarios no se sorprenderá (En cualquier caso, los permisos de UNIX originales siguen funcionando) . LSM marco para que los desarrolladores que desean limitar el método, y la mayor parte de sus desarrolladores confían en que pueden trabajar dentro del marco.
LSM marco para la comprensión de otras restricciones también es importante. LSM marco está diseñado para apoyar el control de acceso, la auditoría y otras cuestiones de seguridad no lo son. LSM propio módulo no registra todas las solicitudes o sus resultados, porque no pueden ver todos. ¿Por qué? Una de las razones es que el kernel no puede poner el módulo LSM se negó la solicitud; Si a usted le gusta la auditoría de este rechazo será un problema. Asimismo, debido a razones de rendimiento, algunas de las propuestas para la rama de anomalías de red y datos de campo LSM no es utilizado por núcleo principal. Puede controlar un número de acceso a la red, pero el apoyo no "etiquetados" Red de flujo de datos (en este caso, los paquetes de datos diferentes son diferentes desde el sistema operativo maneja las etiquetas de seguridad). Estas restricciones son inadecuados, incompatible con los principios básicos de las ideas generales, el marco LSM se ha ampliado un día la esperanza de librarse de estas restricciones.
Sin embargo, aun con estas restricciones, el marco LSM para limitar los privilegios para agregar todavía es muy útil. Torvalds marco LSM por el objetivo fundamental se realiza: "No me gusta la lucha entre grupos de seguridad diferentes. Espero que sea indirecta, me dejó fuera de esta lucha, entonces el mercado pueden tener dificultades para decidir qué estrategia y aplicar para lograr la máxima . "
Así pues, si desea restringir Linux concedido el privilegio de su programa, usted puede crear por completo el módulo de seguridad. Si utiliza una restricción externa real de que sea necesario hacerlo - por suerte esto es posible. Sin embargo, esto es muy importante; de todos modos, usted todavía tiene que escribir el código del kernel. Si es posible, mejor que no use el actual módulo de seguridad de Linux, pero trate de escribir su propio módulo de seguridad. Algunos módulo LSM disponibles, pero, Security-Enhanced Linux (SELinux) es el más maduro de un módulo de seguridad para Linux, así que vamos a examinar este módulo.
Security-Enhanced Linux (SELinux) historia
Un poco de historia ayudará a ayudará a entender la seguridad mejorada de Linux (SELinux) - y él mismo es una historia divertida. Estados Unidos Agencia de Seguridad Nacional (National Security Agency, NSA) de largo se ha preocupado por la seguridad de la mayoría de sistemas operativos, capacidad limitada. Después de todo, uno de ellos es asegurar que los Estados Unidos Departamento de Defensa para utilizar el ordenador frente a ataques sin fin de mantener la seguridad. NSA encontró que la mayoría de los mecanismos de seguridad del sistema operativo, incluyendo Windows y la mayoría de sistemas UNIX y Linux, solo se consigue un control de "acceso selectivo (control de acceso discrecional)" (DAC). sistema de CAD es ejecutar el programa bajo la identidad del usuario y los documentos para determinar el propietario del programa objeto puede hacer. NSA que este es un problema grave, porque el propio CAD vulnerables o maliciosas programa es un fracaso de protección. En cambio, la NSA ha sido durante mucho tiempo la esperanza de que el sistema operativo también puede apoyar el "control de acceso obligatorio (control de acceso obligatorio)" (MAC) mecanismo.
mecanismo MAC permite al administrador del sistema puede definir las políticas de seguridad en todo el sistema, esta estrategia puede basarse en otros factores, tales como la función del usuario, la credibilidad del programa y el uso previsto, el programa utilizará el tipo de datos, etc, para limitar el programa puede Qué hacer cosas. Un pequeño ejemplo, con la MAC vez que el usuario no puede fácilmente "secreto (secreto)" datos en "no confidencial (sin clasificar)" datos. Sin embargo, MAC realmente puede hacer mucho más que eso.
NSA ha estado con los proveedores del sistema operativo por muchos años, pero muchos de los proveedores mayor cuota de mercado de la integración de la MAC no está interesado en llegar. Incluso los proveedores que integra MAC también suele ser utilizado como "productos distintos", en lugar de los productos convencionales. En parte porque el viejo MAC no es lo suficientemente flexible.
Así que la NSA de poder tratar de hacer MAC y más flexible y más fácil de incluir en el sistema operativo. Ellos usan el sistema operativo Mach desarrollado prototipos de sus ideas, y más tarde amplió la labor iniciada por "Fluke" del sistema operativo.
Sin embargo, es difícil convencer a la gente que estas ideas se pueden aplicar a "real" del sistema operativo, porque todos estos se basan en pequeñas "proyecto de investigación del juguete de la clase". Muy pocos fuera del prototipo puede tratar de ver estas ideas en una aplicación real de cómo trabajar. NSA no puede convencer a un distribuidor de título para añadir estas ideas, y la NSA no tenía derecho a modificar el sistema operativo propietario. Esto no es un problema nuevo; años atrás, DARPA trató de forzar su sistema operativo propietario, los investigadores utilizaron el sistema operativo Windows, pero se encontró con muchos problemas (ver referencias abajo).
Así, la NSA se encontró con un pensamiento en retrospectiva parece obvia: usar un juguete no es de código abierto del sistema operativo, y poner en práctica sus ideas de seguridad para demostrar que (1) puede funcionar, (2) que es específica para el trabajo (a través de para todo el código fuente). Eligieron la dominante en el mercado, el núcleo de código abierto (Linux) y en el que la realización de su idea de que "Security-Enhanced Linux (SELinux). No es de extrañar, utiliza el sistema real (Linux) para los investigadores NSA puede tratar con ellos en el juguete no se puede tratar. Por ejemplo, en la mayoría de los sistemas basados en Linux, casi todos están dinámicamente relacionados, así que tuvieron que hacer algunas investigaciones sobre cómo llevar a cabo procedimiento de análisis en profundidad (acceder a ellos en el punto de entrada ", y" ejecutar "permisos a la documentación para obtener más información). Esta es una manera mucho más éxito, las personas que están usando SELinux prototipo antes que aquellos que usan mucho más.
SELinux para trabajar
Por lo tanto, a trabajar por SELinux? Método de SELinux en realidad muy común. Un núcleo importante de cada objeto, como cada objeto del sistema de archivos, y cada proceso tiene una correlación con su contexto de seguridad "(contexto de seguridad)". El contexto de seguridad se puede basar en el nivel de seguridad militar (si no confidencial y confidencial y altamente confidencial), basado en roles de usuario, basado en las aplicaciones (así, un servidor Web puede tener su propio contexto de seguridad), o en muchos otros elementos. Cuando se ejecuta otro programa, el proceso puede cambiar el contexto de seguridad. Incluso, dependiendo del procedimiento lo llaman, un determinado programa puede funcionar en contextos de seguridad diferentes, incluso si un usuario inicia con todos los procedimientos.
Entonces el administrador del sistema puede especificar qué privilegios concedidos a crear un contexto de seguridad con la que la política de seguridad "(política de seguridad)". Cuando la llamada al sistema se produce cuando, SELinux para comprobar si todos los privilegios necesarios se han concedido - y si no, se negó la solicitud.
Por ejemplo, para crear un archivo, el contexto de seguridad del actual proceso de contexto de seguridad del directorio padre sobre la "Búsqueda (búsqueda)" y "privilegio add_name", y que necesita para (crear) archivos en el contexto de seguridad de la Creación "( crear) un privilegio ". Del mismo modo, el contexto de seguridad de ese archivo con el sistema de archivo debe tener el privilegio de "relacionado (asociado)" (Así, por ejemplo, "altamente confidencial" los documentos no se puede escribir un "no confianza" en el disco). También para los enchufes, las interfaces de red, el host y el puerto del control de acceso a la red. Si la política de seguridad para los que están todos los permisos concedidos, a continuación, se considerará la solicitud permitido por SELinux. De lo contrario, que estarán prohibidos. Si lo hace paso a paso todos estos controles será más lento, pero hay muchos programas de optimización (basado en años de investigación) para hacerlo muy rápidamente.
El examen es independiente del sistema de clases en los permisos de UNIX bits habitual; en el sistema de SELinux, es necesario escribir tanto la norma de permisos UNIX, hay SELinux permiso para hacer algo. Sin embargo, los controles de SELinux puede hacer mucho de lo tradicional permisos de UNIX para la clase es difícil de lograr.
Uso de SELinux, usted puede crear fácilmente un programa específico y sólo se puede ejecutar sólo en el contexto de un determinado servidor Web para escribir archivos. Aún más interesante es que si un atacante anotó un servidor Web y se convierta en administrador, el atacante no se le dará el control de todo el sistema - si hay una buena política de seguridad, entonces.
Ha sido difícil: Para que SELinux con eficacia, usted necesita tener una buena razón detrás de la aplicación política de seguridad SELinux. La mayoría de los usuarios necesitarán una práctica fácil de modificar su estrategia inicial. Hace unos años empecé a experimentar el SELinux, entonces, la estrategia inicial no está suficientemente madura, hay muchos problemas. Por ejemplo, en aquellos días antes de encontrar la política de principios de la muestra no permite que el sistema de actualización el reloj de hardware (la última vez que presentó un parche para solucionar este problema). Un buen diseño inicial de la política de seguridad similar a la categoría de productos, NSA espera hacer por la comunidad empresarial, y esperamos que lo haga. Red Hat, una serie de desarrolladores de Debian, Gentoo y otros que están utilizando el marco básico de SELinux, y la política de seguridad inicial se está creando, de manera que los usuarios pueden inmediatamente comenzar a utilizarlo. De hecho, Red Hat planea para todos los usuarios en su funcionamiento tanto en SELinux en Fedora Core, y proporcionar herramientas sencillas para que el usuario no profesional puede seleccionar alguna de las opciones comunes a modificar su política de seguridad. Hay un arranque de Gentoo LiveCD SELinux. Minimizar estos grupos, será más fácil de procesar privilegio, sin una gran cantidad de código.
Aquí estamos de nuevo a la posición original. SELinux permite sólo cuando la ejecución del programa se produce sólo cuando la transmisión segura, que controla el proceso de competencia (no una parte del proceso). Así que, para poner en pleno juego el potencial de SELinux, necesita desfragmenta sus aplicaciones independientes de Jincheng y procedimientos, sólo componentes menores son privilegiados - como si tal y como las condiciones para el desarrollo en You Mo procedimientos de seguridad de SELinux. Herramientas como SELinux le permite controlar mejor la concesión de autoridad, y así crear una defensa más fuerte, pero usted todavía necesidad de dividir el programa en componentes más pequeños para que los que controlan el juego la máxima eficacia.
Conclusión
Minimizar los problemas de seguridad privilegio es la defensa más importante. Como el defecto es inevitable, tendrá que reducir en gran medida la posibilidad de defectos conducen a problemas de seguridad. Sin embargo, por lo menos un programa de seguridad debe estar relacionada con la seguridad de algunas partes del código, por lo que no sólo reduce al mínimo el gasto de todos los privilegios de otros. Incluso cuando usted tiene que reducir al mínimo algunos de los involucrados en la seguridad después de la parte o los que deben ser correctos. A la derecha, es necesario evitar errores comunes.