Cosa fanno effettivamente i meccanismi di autorizzazione di OS X?


13

sfondo 

Sto cercando di ottenere una migliore comprensione del processo di accesso a OS X, al fine di decidere il modo migliore per raggiungere il Single Sign-On VPN .

Per favore, correggimi se sbaglio, ma credo che ...

  1. launchd(8)chiama gettyent(3)e quindi determina da ttys(5)eseguire loginwindow.appper /dev/console.

  2. loginwindow.apptenta di acquisire il system.login.consolediritto di autorizzazione, per il quale il database di autorizzazione specifica i seguenti meccanismi (elencati insieme alla mia comprensione della loro funzione); quelli che sono privilegiati vengono eseguiti all'interno del authdprocesso (come root), mentre quelli che non sono privilegiati vengono eseguiti all'interno del SecurityAgentprocesso (come _securityagent):

    • builtin:policy-banner(visualizza il banner della finestra di accesso , se impostato).
    • loginwindow:login (richiede credenziali).
    • builtin:login-begin
    • builtin:reset-password,privileged(esegue la reimpostazione della password utilizzando l'ID Apple ).
    • builtin:forward-login,privileged (inoltra le credenziali di EFI all'avvio).
    • builtin:auto-login,privileged (applica le credenziali di accesso automatico all'avvio).
    • builtin:authenticate,privileged(invoca pam_authenticate(3)per authorizationil servizio; set valore di contesto "uid").
    • PKINITMechanism:auth,privileged (inizializza Kerberos ottenendo un TGT).
    • builtin:login-success
    • loginwindow:success (protegge la sessione di accesso da accessi remoti non autorizzati; registra l'accesso nei database utmp e utmpx del sistema; imposta il proprietario e le autorizzazioni per il terminale della console).
    • HomeDirMechanism:login,privileged (monta la home directory dell'utente).
    • HomeDirMechanism:status (visualizza l'avanzamento del montaggio della directory home).
    • MCXMechanism:login (applica i profili di configurazione).
    • loginwindow:done (reimposta le preferenze dell'utente in modo da includere le impostazioni di sistema globali; configura il suono del mouse, della tastiera e del sistema utilizzando le preferenze dell'utente; imposta le autorizzazioni del gruppo dell'utente; recupera il record dell'utente dai Servizi di directory e applica tali informazioni alla sessione; carica i computer dell'utente ambiente — comprese preferenze, variabili di ambiente, autorizzazioni per dispositivo e file, accesso al portachiavi e così via; avvia Dock, Finder e SystemUIServer; lancia gli elementi di accesso per l'utente).

Domande

Mi piacerebbe molto confermare la mia comprensione della funzione di ciascun meccanismo:

  1. Il loro codice sorgente è disponibile apertamente? So che i non- builtinmeccanismi sono definiti dai plugin che si possono trovare sotto /System/Library/CoreServices/SecurityAgentPlugins, ma non riesco a trovare la fonte da cui sono stati costruiti. Né posso trovare dove builtinsono definiti i meccanismi.

  2. Se la fonte non è disponibile, i meccanismi sono documentati ovunque?

osservazioni

  1. Come possono loginwindow:loginrichiedere le credenziali se viene invocato prima builtin:forward-login e builtin:auto-login, in entrambi i casi, la GUI viene ignorata? Ispeziona il contesto per tali credenziali e si salta se sono presenti? Sembra strano.

  2. Inoltre, come descritto nel white paper tecnico sull'autenticazione 802.1X di Apple :

    Quando la Modalità finestra di accesso è configurata e un utente digita un nome utente e una password nella finestra di accesso, accadranno due cose. Innanzitutto, la finestra di accesso autenticherà il computer tramite 802.1X sulla rete utilizzando il nome utente e la password immessi dall'utente. Dopo che l'autenticazione 802.1X ha esito positivo, la finestra di accesso autenticherà lo stesso nome utente e password nella directory esterna.

    Poiché la seconda fase di tale autenticazione è gestita dal pam_opendirectory.somodulo e dipende dalla rete presente, la prima fase (autenticazione tramite 802.1X alla rete) deve necessariamente avvenire prima di quella. Cioè, deve avvenire prima del builtin:authenticatemeccanismo.

    Da un'ispezione casuale del file loginwindowbinario del plugin, sembra che gestisca tale autenticazione 802.1X, ma l'unico meccanismo invocato all'interno di quel plugin prima builtin:authenticateè loginwindow:login. Sono corretto nel pensare che questo meccanismo non solo visualizza il prompt di accesso, ma tenta anche l'autenticazione 802.1X? (In tal caso, ciò non solo sembra un po 'IMHO sciatto, ma suggerisce anche che le credenziali di EFI / login automatico non possono essere utilizzate per l'autenticazione della finestra di accesso 802.1X.)

Risposte:


1
  1. Da quello che ricordo loginwindow: login viene effettivamente utilizzato per generare la finestra di login della GUI, simile a builtin: policy-banner. Quindi è logico generarsi prima del resto delle azioni. Quindi la finestra della GUI è quella effettivamente irrilevante / aggirabile, non le credenziali stesse.

  2. Cosa vorresti esattamente modificare e verso quale scopo? Ad esempio, se è necessario invocare il plug-in di autorizzazione in altre situazioni, è possibile farlo modificando auth.db.

Inoltre, incorporato: i sottosistemi di autenticazione dovrebbero gestire la differenza tra 802.1X e l'autent locale.


1
builtin:forward-login,privileged

Inoltra il login FileVault riuscito alla finestra di login di OS X e ignora la necessità di effettuare il login. È un po 'come il single sign-on. Lo disabilito nel mio ambiente poiché non utilizzava il profilo 802.1X che avevo configurato. Vorrei provare a farlo.

OS X: come disabilitare l'accesso automatico quando FileVault è abilitato

sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.