Cómo evitar que incluso los usuarios Root desinstalen o manipulen la aplicación en MacOS

El objetivo es evitar que incluso los usuarios Root desinstalen nuestra aplicación en su mac.

Tú, como desarrollador de terceros, no puedes impedir que el usuario Root o los usuarios con privilegios Root desinstalen aplicaciones que, técnicamente, pueden instalar ellos mismos. Lo que un administrador puede hacer otro puede (des)hacer.

El núcleo del sistema operativo está protegido por SIP y, si se utiliza Catalina o una versión posterior, el volumen del sistema es de sólo lectura. Esto se implementa en la propia capa base y no en la capa de aplicación donde se opera.

Sin embargo, el departamento de TI puede gestionar los permisos, derechos y funciones mediante el uso de software MDM (Mobile Device Management). Una vez que un dispositivo está inscrito, el departamento de TI podrá crear y aplicar políticas que permitan/prohiban el uso y la instalación de software.

Esto lo tiene que gestionar TI, no el desarrollador.

Vas a tener que desactivar el SIP reiniciando en recovery abriendo una ventana de terminal y "csrutil disable" (luego reiniciar en el SO) y proceder a descargar y borrar los archivos kext restantes. A partir de la versión 10.15(catalina) las extensiones del kernel se han colocado en la carpeta /System/Library y sólo se reflejan (o se enlazan simbólicamente) en la carpeta /Library. Por lo tanto, para cambiar los parámetros del sistema; tendrás que desactivar la protección de la carpeta /System (SIP) y luego proceder a descargar los kexts que no vayas a utilizar.

Asegúrese de volver a habilitar csrutil (el mismo método que antes; utilice el comando > csrutil enable)

Además, hace un tiempo (El capitain o sierra [no lo recuerdo ahora y hace tiempo que no deshabilito la basura innecesaria que viene precargada con OSX]); de cualquier manera; -- solía ser posible deshabilitar los kexts a través de la misma terminal en la que podías deshabilitar el SIP (modo de recuperación) o el modo de usuario único. Para entrar en el arranque de usuario único con cmd+s para entrar en el arranque de recuperación con cmd+r

Aconsejo precaución cuando se trate de Parámetros del Sistema; algunos pueden hacer que el sistema no funcione; o al menos... algunos de los servicios que se ofrecen podrían verse gravemente obstaculizados.

Otra posible vía sería a través de la instalación de "Perfiles de configuración aprovisionados", que evitan/bloquean los procesos internos (como si fueran instalados por una organización o un MDM).

No recomiendo intentar bloquear a los administradores. Es mucho mejor gestionar el acceso de los administradores, pero si insistes en que quieres nadar en la dirección opuesta a la de Apple, empieza con un producto como DeepFreeze.

• https://www.faronics.com/products/deep-freeze/

Su solución de gestión de Mac es la mejor si quieres sacrificar las formas modernas más eficientes de controlar los cambios. Ahora bien, una vez que hayas puesto precio a ese software o hayas suscrito una solución "construida por nosotros mismos", busca de nuevo a Apple como socio y conoce lo bien que funcionan DEP y MDM para lograr todos tus objetivos y no sólo el tema de la modificación involuntaria de archivos.

Lo que se busca es la supervisión de MDM y la inscripción de dispositivos. Esa es la forma eficiente y moderna de asegurar los activos corporativos y, como beneficio, sus inscripciones de TI serán de toque cero y aplicadas por Apple. Mojave y los más nuevos están muy bien diseñados y Big Sur tiene algunas palancas masivas para asegurar aún más contra la modificación de archivos fuera de la caja, incluso sin DEP + MDM.

• http://business.apple.com
• https://www.apple.com/business/it/

Apple ofrece asesoramiento y consultoría gratuitos para que cualquier empresa se inicie en este camino y ofrece servicios profesionales de pago cada vez que se quiera un soporte de primera parte o servicios mejorados más allá de las cuentas básicas gratuitas necesarias para asegurar correctamente todos los dispositivos (Mac / iOS / iPadOS / tvOS / watchOS).

Al imponer la notarización y la firma del código, se bloquean todas las modificaciones, ya sean maliciosas o generadas por el usuario.

Las extensiones del kernel (KEXT) pueden impedir que el sistema las descargue. Como no siempre es una buena idea descargar una extensión del kernel que está en uso activo, puede congelar todo el sistema o hacer entrar en pánico al kernel si lo hace, se le pregunta a una extensión del kernel antes de descargarla si está de acuerdo con eso y si lo niega, el sistema no la descargará. Por supuesto, un KEXT puede simplemente alegar siempre que la descarga sería un problema. Así que no puedo descargarlo desde un sistema en funcionamiento.

Y un KEXT puede engancharse a la API del sistema de archivos para supervisar todos los accesos a los archivos e impedir cierto tipo de operaciones de archivo, por ejemplo, una que borre el propio KEXT en el disco o cualquier herramienta de ayuda al espacio del usuario (agente/demonio).

Así que, a primera vista, ese sistema parece a prueba de balas. Pero no lo es. Por ejemplo, nada me impide arrancar en modo de usuario único y borrar el KEXT en ese modo. Nada me impide arrancar el sistema de recuperación y borrar el KEXT en la partición principal. Nada me impide arrancar desde un disco externo y borrar el KEXT en el interno. Y una vez borrado, puedo arrancar el sistema interno normalmente y nada me impide eliminar cualquier otro software que no me guste.

Esto es algo que el maleware no puede hacer fácilmente y tampoco sin que el usuario que está frente al ordenador se dé cuenta. Así que esto detiene el malware y por lo tanto tiene sentido para un escáner de virus, pero no impide que un ser humano sentado frente a dicha máquina lo haga.

Incluso el SIP sólo puede proteger un sistema en funcionamiento. Puedo arrancar en modo de recuperación y manipular los archivos que quiera, incluso los que suelen estar protegidos por SIP. Y la protección SIP no está disponible para los desarrolladores de terceros, es un sistema de protección destinado a proteger el propio MacOS de ser manipulado por malware y hackers.

Y dado que los KEXTs están obsoletos con MacOS 11 y el próximo MacOS 12, esta no es una solución que siquiera consideraría para empezar.