¿Qué hacen realmente los mecanismos de autorización de OS X?


13

Antecedentes 

Estoy tratando de obtener una mejor comprensión del proceso de inicio de sesión de OS X, a fin de decidir la mejor manera de lograr el inicio de sesión único de VPN .

Por favor, corrígeme si me equivoco, pero creo que ...

  1. launchd(8)llama gettyent(3)y por lo tanto determina a partir ttys(5)de ejecutar loginwindow.apppara /dev/console.

  2. loginwindow.appintenta adquirir el system.login.consolederecho de autorización, para lo cual la base de datos de autorización especifica los siguientes mecanismos (enumerados junto con mi comprensión de su función); los que tienen privilegios se ejecutan dentro del authdproceso (como root), mientras que los que no tienen privilegios se ejecutan dentro del SecurityAgentproceso (como _securityagent):

    • builtin:policy-banner(muestra el banner de la ventana de inicio de sesión , si está configurado).
    • loginwindow:login (solicita credenciales).
    • builtin:login-begin
    • builtin:reset-password,privileged(realiza el restablecimiento de contraseña con Apple ID ).
    • builtin:forward-login,privileged (reenvía las credenciales de EFI en el arranque).
    • builtin:auto-login,privileged (aplica credenciales de inicio de sesión automático en el arranque).
    • builtin:authenticate,privileged(invoca pam_authenticate(3)para authorizationservicio; establece el valor de contexto "uid").
    • PKINITMechanism:auth,privileged (Inicializa Kerberos obteniendo un TGT).
    • builtin:login-success
    • loginwindow:success (asegura la sesión de inicio de sesión desde el acceso remoto no autorizado; registra el inicio de sesión en las bases de datos utmp y utmpx del sistema; establece el propietario y los permisos para el terminal de la consola).
    • HomeDirMechanism:login,privileged (monta el directorio de inicio del usuario).
    • HomeDirMechanism:status (muestra el progreso del montaje del directorio de inicio).
    • MCXMechanism:login (aplica perfiles de configuración).
    • loginwindow:done (restablece las preferencias del usuario para incluir valores predeterminados globales del sistema; configura el mouse, el teclado y el sonido del sistema utilizando las preferencias del usuario; establece los permisos de grupo del usuario; recupera el registro del usuario de los Servicios de directorio y aplica esa información a la sesión; carga la informática del usuario entorno: incluidas las preferencias, las variables de entorno, los permisos de dispositivo y archivo, el acceso de llavero, etc., inicia el Dock, Finder y SystemUIServer; inicia los elementos de inicio de sesión para el usuario).

Preguntas

Me gustaría confirmar mi comprensión de la función de cada mecanismo:

  1. ¿Su código fuente está disponible abiertamente? Sé que los no builtinmecanismos están definidos por complementos que se pueden encontrar debajo /System/Library/CoreServices/SecurityAgentPlugins, pero no puedo encontrar la fuente a partir de la cual se construyeron. Tampoco puedo encontrar dónde builtinestán definidos los mecanismos.

  2. Si la fuente no está disponible, ¿están documentados los mecanismos en alguna parte?

Observaciones

  1. ¿Cómo puede loginwindow:loginsolicitar credenciales si se invoca antes builtin:forward-login y builtin:auto-login, cualquiera de los dos causa que se omita la GUI? ¿Inspecciona el contexto para tales credenciales y se salta si están presentes? Parece extraño.

  2. Además, como se describe en el documento técnico de autenticación 802.1X de Apple :

    Cuando se configura el modo de ventana de inicio de sesión y un usuario escribe un nombre de usuario y contraseña en la ventana de inicio de sesión, sucederán dos cosas. Primero, la ventana de inicio de sesión autenticará la computadora a través de 802.1X a la red utilizando el nombre de usuario y la contraseña que ingresó el usuario. Después de que la autenticación 802.1X sea exitosa, la ventana de inicio de sesión autenticará el mismo nombre de usuario y contraseña en el directorio externo.

    Dado que el pam_opendirectory.somódulo maneja la segunda etapa de esa autenticación y depende de la red presente, la primera etapa (autenticación a través de 802.1X a la red) debe ocurrir necesariamente antes de eso. Es decir, debe ocurrir antes del builtin:authenticatemecanismo.

    Según una inspección informal del loginwindowcomplemento binario, parece que maneja dicha autenticación 802.1X, pero el único mecanismo invocado dentro de ese complemento antes builtin:authenticatees loginwindow:login. ¿Estoy en lo cierto al pensar que este mecanismo no solo muestra la solicitud de inicio de sesión, sino que también intenta la autenticación 802.1X? (Si es así, eso no solo parece un poco descuidado en mi humilde opinión, sino que también sugiere que las credenciales de EFI / inicio de sesión automático no se pueden usar para la autenticación de la ventana de inicio de sesión 802.1X).

Respuestas:


1
  1. Por lo que recuerdo loginwindow: login realmente se usa para generar la ventana de inicio de sesión de la GUI, similar a builtin: policy-banner. Por lo tanto, es lógico que se genere antes que el resto de las acciones. Entonces, la ventana de la GUI es la que realmente es irrelevante / omitible, no las credenciales en sí.

  2. ¿Qué le gustaría modificar exactamente y con qué propósito? Por ejemplo, si necesita que se invoque el complemento de autorización en otras situaciones, puede hacerlo editando auth.db.

Además, builtin: los subsistemas de autenticación deben manejar las diferencias entre 802.1X y la autenticación local.


1
builtin:forward-login,privileged

Reenvía el inicio de sesión exitoso de FileVault a la ventana de inicio de sesión de OS X y evita la necesidad de iniciar sesión allí. Es como un inicio de sesión único. Deshabilito esto en mi entorno ya que no estaba usando el perfil 802.1X que había configurado. Intentaría hacer eso.

OS X: Cómo deshabilitar el inicio de sesión automático cuando FileVault está habilitado

sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.