5 días para El Capitan: System Integrity Protection

En OS X 10.11 El Capitan, Apple ha dado un paso muy importante en la protección del sistema integrando una nueva política llamada System Integrity Protection o traducido al castellano, Sistema de Protección de Integridad. El objetivo de esta nueva política de seguridad es proteger el sistema operativo tanto de un mal uso, uso accidental o modificación por parte del usuario como por parte de software de terceras partes, específicamente el software malicioso.

OS X aplica esta política de seguridad a todos los procesos que se ejecutan en el sistema, da igual que se ejecuten con derechos de administrador o fuera del sandbox del sistema o aplicaciones. Por defecto, las aplicaciones descargadas desde la Mac App Store no tienen problemas para ejecutarse bajo este nuevo esquema de seguridad, pero las aplicaciones externas si podrían verse afectadas por System Integrity Protection, especialmente aquellas que han sido desarrolladas sin firmado de código o que pretenden acceder al sistema para instalar archivos de soporte para las aplicaciones en ubicaciones que por defecto Apple ha eliminado de la lista de carpetas accesibles para la instalación de software.

Mal llamado Rootless, ya que esta característica es solo una parte de esta política relativa a el acceso a ciertas ubicaciones especiales del disco, System Integrity Protection reúne algunas características ya implementadas en OS X 10.10 Yosemite y añade otras nuevas que además se gestionan de forma unificada a través de una utilidad nueva que se ejecuta a través del Terminal y no siempre desde tu cuenta de usuario, sino que en algunas ocasiones, para modificar el comportamiento de System Integrity Protection es necesario reiniciar a la partición de recuperación, que se convierte en parte importante de la seguridad de tu Mac bajo OS X 10.11 El Capitan.

System Integrity Protection (SIP) está diseñado sobre todo para proteger al usuario menos experimentado de problemas, específicamente del malware en el Mac. Con SIP activado, es mucho más difícil para un software malicioso integrarse dentro del sistema ya que al haber una serie de ubicaciones críticas fuera de su alcance, resulta complejo para esa aplicación maliciosa, por ejemplo, reinstalarse si es borrada, iniciarse para todos los usuarios al arrancar al Mac y más.

Cuando se actualiza desde una versión anterior de OS X a una con SIP, el sistema migra cualquier contenido de terceras partes como parte del proceso de instalación, moviendo esos archivos a una ubicación temporal para luego instalar los archivos del sistema y a continuación, determinar uno a uno si esos archivos tienen la opción de poder convivir dentro de un OS X con SIP activado y son movidos a su ubicación original. Si el sistema determina que los archivos no son válidos, serán desplazados a la carpeta:

/Library/PreviousSystems

que se crea con el propósito de preservar la información tras una la actualización del sistema.

Ubicaciones restringidas

Como ya he explicado, hay ciertas ubicaciones restringidas a lo largo del sistema en las que resultará imposible instalar nada, incluso por parte de un usuario administrador con una contraseña válida si SIP está activo. Estas ubicaciones, en las que solo puede escribir el sistema, incluyendo los subdirectorios, son:

  • /bin
  • /sbin
  • /usr
  • /System
  • /Aplicaciones/Utilidades

Todos los directorios dentro de /usr excepto /usr/local están restringidos al Sistema. las aplicaciones de Apple en la carpeta de Aplicaciones también están restringidas al Sistema.

Lenguajes de Script

Para los usuarios o desarrolladores que utilicen Perl, Python, Ruby o cualquier otro lenguaje de scripting distribuido con OS X se les recomienda bajo SIP que gestionen sus propias instalaciones y dependencias en:

/usr/local/

Adicionalmente Apple recomienda a los desarrolladores que cuando distribuyan aplicaciones creadas con este tipo de lenguajes, empaqueten en runtime y cualquier componente necesario para la ejecución del mismo dentro del binario de la aplicación.

Protecciones Runtime

Cuando se incia un proceso, el kernel comprueba si el ejecutable que lo ha generado está protegido o firmado de forma especial por el sistema. Si el kernel lo da por válido, lo marca como protegido contra modificación. Cualquier intento de adjuntar algo a un proceso protegido será inmediatamente denegado por el kernel, incluso si este es invocado como root o con sudo. Esto protege los procesos iniciados y firmados creando una cadena de confianza de forma que ninguna aplicación pueda asociar procesos sobre otra aplicación o sobre si misma.

Dtrace ya no puede ser utilizado para inspeccionar procesos del sistema, ya sea desde Instruments o desde la línea de comandos usando dtrace.

Al respecto de los desarrolladores, SIP no previene el uso de estas políticas de seguridad a la hora de inspeccionar las propias aplicaciones mientras se desarrollan. Se podrá seguir utilizando Instruments y LLDB para eliminar errores desde Xcode.

Extensiones de Kernel desde Yosemite a El Capitan

En OS X 10.10 Yosemite Apple introdujo la protección de las extensiones de kernel que debían estar firmadas por el desarrollador para ser utilizadas por el sistema.

El firmado de las extensiones de Kernel está diseñado como medida de seguridad, para evitar que un programa malicioso instale una extensión a nivel del sistema y pueda obtener datos o controlar el ordenador. Sin embargo, esta medida de seguridad impide la utilización de software legítimo que podría funcionar pero que no tiene sus extensiones firmadas. Un caso muy habitual es el de las tarjetas de sonido especializadas cuyos fabricantes no han actualizado sus drivers y lo que es peor, no tienen intención de hacerlo. Al instalar estos drivers en Yosemite pueden ocurrir dos cosas: que el sistema arranque pero no se cargue la extensión y por lo tanto, no se pueda utilizar la tarjeta o lo que es peor, medio del arranque de Yosemite te salga un símbolo de prohibido y se interrumpa el arranque (y entres en pánico).

¿Cuál es el siguiente paso lógico si quieres instalar un driver con extensiones de Kernel no firmadas (pero de confianza) en Yosemite? Desactivar esa protección, una tarea sencilla que sin embargo puede causarte problemas si no te has preparado convenientemente para desactivarla si se vuelve a activar.

La desactivación de la protección se realiza pasando un argumento a la NVRAM, una porción de memoria que se lee al arrancar tu Mac y que almacena una serie de parámetros que se utilizan durante el arranque. El problema es que una de las tareas de mantenimiento más comunes a la hora de solucionar incidencias en el Mac es reiniciar los valores de esta porción de memoria a los parámetros por defecto y entre los parámetros por defecto se encuentra la activación de esta protección de extensiones de Kernel con lo que te puedes encontrar con que el sistema no arranca (el signo de prohibido) y la situación puede complicarse bastante sobre todo si no tienes un buen nivel técnico para salir del atolladero.

Para desactivar la protección de las extensiones de Kernel, era necesario abrir el Terminal, que está en Aplicaciones > Utilidades y usaras el siguiente comando:

sudo nvram boot-args=“kext-dev-mode=1

La sintaxis del comando está bastante clara ya que el valor que define si esta protección está activada sé define en el 1 o el 0 al final del argumento.

Una vez introducido el comando, solo había que reiniciar el ordenador (ya que es un parámetro para la nvram y solo se leerá durante el inicio) y se desactivará la protección, lo que te permitía, ahora sí, hacer la instalación de ese driver de tarjeta de sonido, vídeo, etc. Evidentemente eso no garantizaba que la tarjeta vaya a funcionar porque simplemente el driver puede ser incompatible, pero eso ya es otro problema.

Sin embargo, en OS X 10.11 El Capitan esta forma de pasar un argumento a la nvram es ahora obsoleta y por lo tanto no funciona.

csrutil

Con el OS X 10.11 El Capitan se añade una nueva utilidad para ser gestionada desde la línea de comandos: csrutil.

System Integrity Protection tiene seis categorías diferenciadas: Apple Internal, Kext Signing, Filesystem Protections, Debugging Restrictions, DTrace Restrictions y NVRAM Protections, todas ellas gestionadas por csrutil.

Con esta utilidad podemos configurar parcialmente System Integrity Protection porque algunas funciones están reservadas exclusivamente al uso desde la partición de recuperación.

La información disponible (al menos hasta la Developer Preview 7, pero muy posiblemente válida ya hasta la versión final) es la siguiente cuando introduces csrutil en el Terminal:

  • clear: borra la configuración existente. Solo disponible a través de la partición de recuperación.
  • Disable: desactiva la protección. Solo disponible a través de la partición de recuperación.
  • Enable: activa la protección. Solo disponible a través de la partición de recuperación.
  • Status: muestra la actual configuración.
  • netboot add <dirección>: utiliza una nueva dirección IPv4 de una lista predefinida para permitir el arranque vía red (NetBoot)
  • netboot list: lista las direcciones disponibles para el arranque la red.
  • netboot remove <dirección>: elimina una IP de la lista de direcciones de red disponibles para arranque.

El uso de netboot list es importante para los administradores de redes de Mac desde OS X Server para los arranques remotos desde el servidor, ya que será necesario para la configuración de estos ordenadores comprobar si la IP del servidor está dada de alta en la lista de permitidas si no es posible, tras actualizar a OS X 10.11 El Capitan, arrancar desde OS X Server. Esta operación la puedes realizar desde la partición de recuperación.

Ahora hay que ponerse con la configuración de System Integrity Protection, teniendo en cuenta que todas estas opciones hay que hacerlas desde el Terminal de la partición de recuperación, así que la vas a necesitar o al menos, una partición de recuperación estándar de OS X 10.11 El Capitan en una memoria USB de arranque.

Las configuraciones disponibles son:

Configuration:

  •   Apple Internal: disabled
  •   Kext Signing: disabled
  •   Filesystem Protections: enabled
  •   Debugging Restrictions: enabled
  •   DTrace Restrictions: enabled
  •   NVRAM Protections: enabled

Y pueden ser activadas o desactivadas en función de los intereses del usuario usando sudo bajo la partición de recuperación, por ejemplo:

sudo csrutil enable --no-internal
sudo csrutil enable --without kext
sudo csrutil enable --without fs
sudo csrutil enable --without debug
sudo csrutil enable --without dtrace
sudo csrutil enable --without nvram

¿Debo desactivar SIP?

Si quieres la respuesta corta es “No”.

SIP está pensado para proteger al usuario de cualquier amenaza, incluyendo su propia estupidez. De forma bastante frecuente tendemos a pensar en que la “media de usuario” tiene unos conocimientos similares a los nuestros o por encima, cuando realmente la gran mayoría de usuarios de cualquier dispositivo electrónico son usuarios de aplicaciones y servicios, no de sistemas operativos, así que la aproximación proactiva de Apple al respecto de la seguridad intentado proteger al usuario antes de que ocurra “una desgracia” es en general para la base de usuarios mucho más cómoda que una política “reactiva” que intenta solucionar los problemas conforme van saliendo en forma de actualizaciones que no siempre se instalan. Además, SIP, como política de protección proactiva, es una medida disuasoria ante el desarrollo y despliegue de malware porque si hay algo que busca un criminal es que la infección sea fácil de desarrollar y se distribuya fácilmente y con SIP activado hace falta hacer un largo y complejo trabajo de investigación y desarrollo previo para encontrar una vulnerabilidad que permita sobrepasar SIP.

Para quien sí puede resultar un problema la implementación de SIP es para los Power Users y Profesionales que están acostumbrados a un nivel de personalización muy profundo del sistema operativo ya sea por razones profesionales o personales. Para estos usuarios SIP es definitivamente un problema porque va a interceptar muchas modificaciones, generalmente manuales, que se hacen al sistema para que se adapte un poco mejor a nuestras necesidades.

Adicionalmente, Apple va a hacer especial incidencia en mantener la integridad de SIP al máximo nivel, por lo que es muy factible que con cada  actualización del sistema se reactive SIP con lo que todas las modificaciones realizadas hasta ese momento en el sistema no solo se desactiven sino que dejen por defecto el sistema inutilizable en algún momento, especialmente en el arranque como ocurría en OS X 10.10 Yosemite con las extensiones no firmadas.

Así que no queda otro remedio que abrazar SIP con todas sus consecuencias y buscar alternativas en el caso de tener que modificar el sistema, empezando por la virtualización, el uso de servidores locales externos para desarrollo web o tener que estar pendiente de los últimos tutoriales para realizar ajustes finos al sistema pasando por encima de SIP.

El texto de este artículo, por cierto, está extraído de “Ponte al mando de OS X 10.11 El Capitan“, el nuevo libro de la Editorial Faq-mac que estará disponible el 30 de septiembre junto con el lanzamiento de la nueva versión de OS X. Con más de 200 páginas y 40 minutos de vídeo,  “Ponte al mando de OS X 10.11 El Capitan” te va a permitir conocer todas las novedades y entresijos de El Capitan además de incluir varios capítulos dedicados a explicar las interioridades del sistema y más de 20 trucos en la primera edición. “Ponte al mando de OS X 10.11 El Capitan” incluye garantía de actualización, de forma que si compras el libro, recibirás en posteriores actualizaciones toda la información sobre el sistema, más trucos y tutoriales, hasta componer la mejor y mayor obra escrita en español sobre OS X 10.11 El Capitan.

0 0 votos
Article Rating
Subscribe
Notify of
6 Comments
Oldest
Newest Most Voted
Opiniones Inline
Ver todos los comentarios
Wynztech
Wynztech
8 years ago

Hola Carlos, no te conocia pero a partir de ahora te seguire muy de cerca (bueno, seguire tus escritos). Ya que he migrado de Linux a OS X y no encontraba informacion de nivel en Castellano, llevo varios dias siguiendo tu blog y desde luego es l oque necesito por que sin animo de ofender a nadie vaya nivelazo que gastan los otros que he mirado, madre mia.

Al respecto de SIP no lo he tocado mucho pero va a ser un buen tocanarices para los tocones como yo. Nisiquiera me dejaba añadir un perfil de color (ProPhoto) y ahi va un consejo.

Antes de desactivar SIP por que no os deje añadir o modificar algo intentad añadirlo o modificarlo en vuestro Directorio de Usuario (en el cual teneis vuestra propia Library/ ahi es donde he metido el perfil de color). es mas recomendable asi ya que si rompes algo rompes solo tu ~/home y no el sistema, SIP no es activo ahi por que no afecta al sistema.

Y si no se puede no se puede, desactivarlo bajo vuestra propia cuenta y riesgo.

Saludos.

Fai
Fai
8 years ago

Hola Carlos, he empezado a leer el libro, y este extracto del mismo es excelente. Me aclara muchas dudas sobre SIP, pero no acabo de entender varias cuestiones.

Te comento mi caso después de una instalación limpia de El Capitan en el MB Pro:

Resulta que tengo un instalador xx.pkg, el cual instala varias carpetas y librerías (archivos) en lo más profundo del sistema, concretamente en System/Library/…/lib.

En Yosemite, no había ningún problema para instalarlo, pero en El Capitan da problemas, porque el instalador empieza a instalar y de repente sale un aviso de que no es compatible y no me deja seguir.

Según deduzco, salvo error mío, podría ser que no se instale por falta de firmado de código, por lo que te pregunto si:
1- ¿es posible desactivar SIP e instalar ese xx.pkg para probarlo?
2- Y una vez instalado, y suponiendo que funcionen las librerías, ¿es posible volver a activar SIP, o daría algún error?

En definitiva, lo que me interesa probar es: instalar ese xx.pkg desactivando SIP, y después, una vez comprobado su funcionamiento, volver a activar SIP para estar protegido. ¿Es posible?

3. ¿Qué comando de terminal desde la partición de recuperación debería usar para permitir instalar archivos en el sistema?

Un saludo.

Fai
Fai
8 years ago

Es un paquete de librerías destinada al uso de tarjetas criptográficas tipo dnie, pero que se instala en el sistema del capitan, de tal forma que hasta creaba su propio llavero cuando se insertada la tarjeta en el lector, pudiendo incluso firmar correo electrónico desde el propio Mail con una cuenta específica, y encriptarlo.
Se trata del software bit4id middleware, que funciona en Yosemite, pero no en el capitán. Esperemos que los desarrolladores lo actualicen pronto. Con lo que me comentas, no me arriesgo a hacer “pruebas raras” .

Gracias, y un saludo

6
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x