Mac OSX: cómo proteger con contraseña un archivo .app u otra carpeta para que no sea eliminado/movido por el usuario/administrador/raíz

Estoy trabajando en un agente de seguridad. En el que no quiero permitir que ningún usuario/administrador/raíz elimine normalmente mi aplicación de agente de seguridad.

Si el usuario/administrador/raíz intenta eliminar el archivo .app, el sistema operativo debería mostrar el cuadro de diálogo de contraseña. Si el usuario conoce la contraseña, solo debe eliminarla.

Cualquier puntero sobre esto sería útil.

No puede evitar que la raíz haga nada (o sudo rm) ya que los usuarios miran los permisos de archivos de Unix
sudo pediría una contraseña.
Con el debido respeto, Mark está equivocado; ver mi respuesta a continuación. Los usuarios administradores conocerán la contraseña de sudo, por lo que los permisos de archivo de Unix no son una respuesta a la pregunta de op.

Respuestas (1)

Descargo de responsabilidad

Esta respuesta no pretende ser un consejo de seguridad para los usuarios habituales. Establecer el nivel de seguridad de su Mac en 1 podría causar el mal funcionamiento de ciertos controladores de software o hardware, por lo que le aconsejo que haga su propia diligencia debida e investigación y pruebas independientes para determinar si podría haber consecuencias no deseadas al realizar estos pasos.

La sección 5.4.2 del artículo vinculado a continuación sobre las características de BSD relacionadas con las restricciones de seguridad en el superusuario es un buen lugar para comenzar. http://docstore.mik.ua/orelly/other/puis3rd/0596003234_puis3-chp-5-sect-4.html

En caso de que ese enlace se rompa en el futuro, la sección más importante del artículo enumera los efectos de la configuración kern.securelevel=1:

El acceso de escritura a las particiones de disco sin formato está prohibido. (Esto obliga a que todos los cambios en el disco pasen por el sistema de archivos).

El acceso directo al controlador de bus SCSI está prohibido.

Los archivos que tienen el indicador inmutable establecido no se pueden cambiar. Los archivos que tienen establecido el bit de solo agregar solo se pueden agregar y no se pueden modificar ni eliminar de otra manera.

El contenido de los paquetes IP no se puede registrar.

La E/S sin procesar a la consola del sistema está prohibida.

Se prohíben las escrituras sin formato en la memoria del sistema o en los controladores de dispositivos de E/S desde los programas del usuario.

Se deniega cierto acceso al sistema de archivos /proc de Linux.

No se pueden cargar módulos de kernel adicionales.

El reloj del sistema no se puede configurar hacia atrás. Además, no se puede adelantar más de un segundo como máximo, y solo se puede adelantar una vez por segundo (efectivamente, el reloj se puede adelantar como máximo al doble de la hora).

Esta lista no es completa.

TLDR: la configuración kern.securelevel=1podría tener más consecuencias que las que se describen en los pasos a continuación. Ten cuidado.

Dicho esto, probé estos pasos en un iMac normal con OS X 10.10.2 y no noté ningún problema como resultado. En el pasado, securelevel 1era la configuración predeterminada para OS X, y las páginas de manual en OS X 10.10 todavía indican indirectamente que 1es la configuración predeterminada (dicen que debe reiniciar en modo de usuario único para eliminar schg, que requiere securelevel 0).

Sin embargo, en realidad, securelevel 0ha sido la configuración predeterminada desde OS X 10.5. Cuando la comunidad en línea se enteró de que Apple cambió silenciosamente el valor predeterminado a 0, algunos administradores de sistemas en los hilos de debates de Apple calificaron de "inconcebible" que Apple hiciera esto. También encontré algunas guías de seguridad en línea que dicen que la configuración kern.securelevel=1es un paso importante para proteger tu Mac. YMMV.

Resumen de respuestas

Siempre que configure una contraseña de firmware en una Mac, puede hacer que cualquier archivo en esa Mac no pueda ser eliminado por nadie, simplemente usando este simple comando de Terminal:

sudo chflags schg /path/to/file

Luego, asegúrese de que su Mac siempre se inicie en el nivel seguro 1 haciendo lo siguiente:

sudo vi /etc/sysctl.conf

Una vez en el editor vi, escriba ipara ingresar al modo de inserción, luego escriba kern.securelevel=1. Luego presione enter, luego dos puntos, luego escriba wqy presione enter.

Por último en Tipo de terminal:

sudo chflags schg /etc/sysctl.conf
sudo sysctl kern.securelevel=1

Ahora que el nivel de seguridad es 1 y el schgindicador está configurado, el archivo no se puede eliminar a menos que el sistema se reinicie en modo de usuario único.

Si se ha establecido una contraseña de firmware, necesitará esa contraseña para acceder al modo de usuario único. Además, lo necesita para ingresar al modo de disco de destino o cambiar el disco de inicio.

Con el indicador schg establecido, incluso la raíz no puede eliminar el archivo. Nadie puede modificarlo desde el Finder o Terminal. Aparecerá bloqueado en el Finder, pero la casilla de verificación bloqueada siempre permanecerá atenuada, pase lo que pase, incluso con una contraseña de administrador. En la Terminal, sudo rm /path/to/fileahora fallará, diciendo "Operación no permitida". Además, sudo SetFile -a l /path/to/filefallará con "ERROR: Error inesperado. (-5000)". :D

Para eliminar este archivo, alguien deberá usar la contraseña del firmware para reiniciar en modo de usuario único, luego desactive el indicador schg con este comando:

sudo chflags noschg /path/to/file

Después de eso, se puede eliminar.

ACTUALIZACIÓN: pasos adicionales críticos necesarios para que la respuesta funcione

Actualización añadida el miércoles. 18 de marzo de 2015 ~ 1:20 p. el archivo sysctl.conf en un nuevo directorio /private/etc y reiniciando. Esto haría que el nivel seguro volviera a cero.

Para evitar esto, después de realizar los pasos anteriores, también debe ejecutar los siguientes comandos:

sudo chflags schg /private
sudo chflags -h schg /etc

El primer comando hace que el directorio /private y sus subdirectorios no puedan cambiarse de nombre. El segundo comando hace que el enlace simbólico de nivel raíz a /private/etc sea imposible de renombrar o eliminar. (El -hargumento hace que chflags actúe sobre el enlace simbólico en sí, en lugar de actuar sobre el objetivo del enlace simbólico).

Advertencias principales

  1. Si estás en un Hackintosh o Mac Pro con una tarjeta gráfica de PC no oficial que no ha sido flasheada con el firmware oficial de Apple o algo funcionalmente idéntico a eso, este truco no funcionará. No estoy seguro de si pueden arrancar en modo de usuario único, por lo que si establece el archivo sysctl.conf y lo configura en schg, puede ser así para siempre. Lo que significa que los archivos configurados en schg nunca se pueden eliminar.

  2. Puede haber algunas formas físicas de restablecer la contraseña del firmware quitando la memoria RAM o eliminando el archivo quitando el SSD/HDD y conectándolo a otra computadora.

Explicación de la respuesta

Para configurar una contraseña de firmware para su Mac, siga los pasos que se muestran cuando busca en Google, "cómo configurar una contraseña de firmware en una Mac". Brevemente los pasos son:

  • Reiniciar en modo de recuperación

  • Seleccione Utilidad de contraseña de firmware en el menú Utilidades y configure la contraseña

  • ...

  • ¡GANANCIA!

Explicación de las advertencias

Tenga en cuenta que en Mac con RAM extraíble, un pirata informático puede restablecer su contraseña de firmware cambiando la cantidad de RAM y luego borrando su PRAM varias veces. Entonces, en Mac como esa, tome las medidas de seguridad física apropiadas para evitar el acceso manual a los componentes internos de la computadora.

Baste decir que debe llegar al nivel seguro 0 para chflags noschgque funcione, y normalmente la única forma de volver al nivel seguro 0 es reiniciar en modo de usuario único. Nuevamente, esto podría ser imposible si su Mac carece de firmware de Apple. Si está paranoico/inseguro, puede ver su nivel de seguridad actual escribiendo sysctl kern.securelevelen Terminal; ¡siempre debe ser 1 después de que se hayan seguido los pasos a menos que esté en modo de usuario único!

Notas adicionales

Hasta donde yo sé, y corríjame si me equivoco, pero la única forma de evitar una contraseña de firmware (aparte de restablecerla mediante el truco de eliminación de RAM) es eliminar el disco duro principal o SSD de la computadora en cuestión, y acceda a él desde otra computadora usando un adaptador SATA a USB, o algo similar. (Las agencias gubernamentales y/o Apple pueden tener una puerta trasera secreta y clasificada... pero si lo persiguen, entonces probablemente desee eliminar archivos, no evitar que se eliminen :D).

Entonces, técnicamente hablando, configurar schg realmente solo resuelve su problema con 100% de infalibilidad si tiene una de las Mac más nuevas sin RAM reemplazable y sin disco duro reemplazable (es decir, una Retina MacBook Pro, MacBook Air, etc.) y usted configure su contraseña EFI, porque esas son las únicas Mac sin RAM extraíble o SSD extraíble. (Por supuesto, si alguien saca su disco solo para borrar un archivo, de nuevo, probablemente tenga problemas peores, como, amigo, ¿dónde está mi disco duro?)

La falta de RAM "reemplazable por el usuario" del iMac de 21,5" hace que sea mucho más difícil eludir la contraseña de EFI y robar RAM, que probablemente sea la razón por la que Apple lo hizo de esa manera, ya que está destinado en gran medida para su uso en escuelas donde los niños pueden eludir y lo harán. alguna medida de seguridad :D (lo sé porque en mi época solíamos hackear AtEase en System 7 para jugar Marathon...)

En iMacs que no sean de 21.5", puede evitar el truco de eliminación de RAM/reinicio de contraseña de firmware invirtiendo $ 40-50 en un candado de la marca Maclocks para iMac. Entra en el puerto de seguridad y tiene una placa de metal que cubre la energía socket donde está la liberación de la escotilla de RAM. Con ese bloqueo físico en su lugar, alguien necesitaría una sierra de diamante o similar para eliminar su archivo protegido por schg ... y si las personas están llevando sierras de diamante a sus computadoras, entonces tiene mucho Hay peores problemas de los que preocuparse que la eliminación de un archivo, como, amigo, ¿dónde está mi computadora?

sudo chflags noschg /path/to/file; sudo rm /path/to/filefunciona para mí incluso sin recurrir al modo de usuario único.
¿Qué tipo de Mac estás usando? Si es Mac Pro o Hackintosh, ¿qué tipo de GPU tiene? ¿En qué versión de OS X estás? ¿ Cuál es el resultado de ejecutar sysctl kern.securelevelen la Terminal?
El sistema es un Mac mini de finales de 2012 que ejecuta 10.10.2, kern.secureleveles 0. Consulte pastebin.com/b2LNg7S1 para ver la transcripción.
¿Configuró su contraseña de firmware EFI?
No, planee la instalación estándar y simplemente ejecute los comandos en la transcripción de pastebin.
OK, déjame verificarlo, habrá otro paso necesario para establecer el nivel seguro en 1.
OK, he actualizado la respuesta, funcionará para usted ahora. Me equivoqué acerca de que el firmware EFI estableciera el nivel seguro; debes hacerlo con un archivo llamado /etc/sysctl.conf. Los pasos adicionales necesarios implican crear ese archivo, luego protegerlo con chflags schg y luego configurar el nivel seguro. Creo que las versiones anteriores de OS X pueden haber predeterminado el nivel seguro 0. No sé si configurarlo en 1 podría afectar la funcionalidad del sistema, ya que hace más que solo evitar el noschg. Ver docstore.mik.ua/orelly/other/puis3rd/…
¿Qué puede hacer si arranca desde una partición de recuperación o desde una unidad USB arcade?
Puedo pensar en un par de formas de evitar esto. Primero, si bien el archivo puede estar bloqueado, aún sería posible cambiar el nombre del directorio en el que se encuentra y reemplazarlo con un casi duplicado (solo falta el archivo "bloqueado"). Para evitar esto, necesitaría bloquear al menos todos los demás directorios en su ruta... y bloquear / o cualquiera de las carpetas de nivel superior debajo de él probablemente causaría problemas. En segundo lugar, creo que una extensión del kernel podría eludir la parte del sistema de archivos que impone el indicador schg, y la raíz puede cargar extensiones.
@Gordon: también estoy pensando en la misma línea. Creación de una extensión del núcleo. Pero no lo he escrito antes, así que no sé cómo empezar. ¿Cómo funcionará exactamente? ¿Puedes publicar alguna URL para referirte a esto?
@Mark Con respecto a una memoria USB, no sé si el sistema le permitirá cambiar su disco de inicio después de configurar la contraseña del firmware EFI. En cuanto a la partición de recuperación, tampoco estoy seguro, pruebe y háganoslo saber.
@Gordon: puede cambiar el nombre del directorio en el que se encuentra, pero no puede reemplazar el directorio. Y después de todo, ¿a quién le importa si cambia el nombre del directorio en el que se encuentra? Simplemente use un fileReferenceURL o un alias de Finder, no les importa si cambia una ruta. En cuanto a una extensión del kernel que pasa por alto el nivel seguro, hay formas de evitar que las personas introduzcan extensiones del kernel en su sistema.
@Omkar Nunca he escrito una extensión de kernel, por lo que no puedo ofrecer muchos consejos, excepto decir que si no está particularmente familiarizado con el kernel, su extensión tiene buenas posibilidades de crear problemas de seguridad .
@CommaToast depende exactamente de cómo se cargue. Si es a través de un elemento en /Library/LaunchDaemons, sería por ruta, no por fileReferenceURL o alias. Además, su oponente podría reemplazar /Library/LaunchDaemons y deshabilitarlo de esa manera, o reemplazar /private/etc y, por lo tanto, eliminar la configuración de nivel seguro en el próximo reinicio.
@Gordon Buenos puntos. Pero todo lo que tiene que hacer es establecer /private en schg. Ni él ni sus hijos directos pueden modificarse, pero sus nietos (excepto sysctl.conf) aún pueden. El contenido de /private nunca cambia, así que no es gran cosa, ¿verdad? En cuanto a cómo funcionan las extensiones del núcleo, no estoy seguro de por qué estamos hablando de ellas. No está claro lo que Okmar está tratando de lograr.
Basado en la falla que señaló @GordonDavisson, actualicé la respuesta principal con pasos adicionales para evitar el cambio de nombre de /private/etc o el enlace simbólico /etc, que podría usarse para omitir el archivo sysctl.conf y configurarlo sin necesidad securelevel 0de contraseña de firmware. También agregué un descargo de responsabilidad para que las personas aleatorias que se encuentren con esto no se causen problemas.
@CommaToast Wow, no tenía idea de que securelevel=1 tuviera efectos de tan largo alcance (y me pregunto cuánto de eso se aplica a OS X; es posible que tenga que hacer algunas pruebas). Bloquear /private y /etc debería solucionar mi preocupación por reemplazar /private/etc, pero no veo una forma similar razonable de bloquear, por ejemplo, un elemento en /Library/LaunchDaemons. Bloquear un sistema contra un atacante con acceso de root es muy, muy difícil , y creo que en algún momento tienes que llamarlo lo suficientemente bueno. Por cierto, Apple tiene una puerta trasera para restablecer los PW de firmware, solo requieren prueba de propiedad antes de desbloquear.
@GordonDavisson Una vez que bloquee /private y el enlace simbólico /etc, y siga los otros pasos en la respuesta, puede bloquear otras cosas de manera que no puedan desbloquearse o eliminarse sin la contraseña de EFI. Entonces, si tiene un LaunchDaemon que desea bloquear, simplemente bloquéelo de esa manera y colóquelo en /System/Library/LaunchDaemons, luego bloquee /System/Library. También puede ponerlo en /Library/LaunchDaemons y bloquear /Library, pero eso podría causar problemas si intenta instalar cualquier software que quiera poner cosas en /Library. Pero si le preocupa la seguridad, probablemente sea bueno.