O que os mecanismos de autorização do OS X realmente fazem?

Question

Antecedentes

Estou tentando entender melhor o processo de login do OS X, para decidir a melhor maneira de obter VPN Single Inscreva-se .

Por favor, corrija-me se estiver errado, mas acredito que -

1. launchd(8) chamadas gettyent(3) e, assim, determina de ttys(5) para executar loginwindow.app para /dev/console .

2. loginwindow.app tenta adquirir o direito de autorização system.login.console , para o qual o banco de dados de autorização especifica os seguintes mecanismos (listados junto com minha compreensão da função deles); aqueles que são privilegiados correm dentro do authd process (como root), enquanto aqueles que não são privilegiados correm dentro do SecurityAgent process (como _securityagent):

   • builtin:policy-banner (exibe Faixa da janela de login , se definida).
   • loginwindow:login (solicita credenciais).
   • builtin:login-begin
   • builtin:reset-password,privileged (executa redefinição de senha usando o ID da Apple ).
   • builtin:forward-login,privileged (encaminha as credenciais do EFI na inicialização).
   • builtin:auto-login,privileged (aplica credenciais de login automático na inicialização).
   • builtin:authenticate,privileged (invoca pam_authenticate(3) para authorization service; define o valor de contexto "uid").
   • PKINITMechanism:auth,privileged (inicializa o Kerberos obtendo um TGT).
   • builtin:login-success
   • loginwindow:success (protege a sessão de login contra acesso remoto não autorizado; registra o login nos bancos de dados utmp e utmpx do sistema; define o proprietário e as permissões para o terminal do console).
   • HomeDirMechanism:login,privileged (monta o diretório pessoal do usuário).
   • HomeDirMechanism:status (exibe o progresso da montagem do diretório inicial).
   • MCXMechanism:login (aplica perfis de configuração).
   • loginwindow:done (redefine as preferências do usuário para incluir padrões globais do sistema; configura o mouse, teclado e som do sistema usando as preferências do usuário; define as permissões de grupo do usuário; recupera o registro do usuário dos Serviços de Diretório e aplica essas informações à sessão; o ambiente de computação do usuário - incluindo preferências, variáveis de ambiente, permissões de dispositivos e arquivos, acesso de chaves, etc. - inicia o Dock, o Finder e o SystemUIServer; inicia os itens de login para o usuário).

Perguntas

Eu gostaria muito de confirmar minha compreensão da função de cada mecanismo:

1. O código-fonte deles está disponível abertamente? Eu sei que os mecanismos que não são builtin são definidos por plug-ins que podem ser encontrados em /System/Library/CoreServices/SecurityAgentPlugins , mas não consigo encontrar a fonte que eles foram construídos. Nem posso encontrar onde os mecanismos builtin estão definidos.

2. Se a fonte não estiver disponível, os mecanismos estão documentados em algum lugar?

Observações

1. Como o loginwindow:login pode solicitar credenciais se for invocado antes builtin:forward-login e builtin:auto-login , sendo que uma delas faz com que a GUI seja ignorada? Ele inspeciona o contexto para essas credenciais e pula-se se elas estiverem presentes? Parece estranho.

2. Além disso, conforme descrito no documento técnico da Apple Autenticação 802.1X :

   When Login Window Mode is configured and a user types in an user name and password at the login window, two things will happen. First, the login window will authenticate the computer via 802.1X to the network using the user name and password the user entered. After the 802.1X authentication is successful, login window will authenticate the same user name and password to the external directory.

   Como o segundo estágio dessa autenticação é tratado pelo módulo pam_opendirectory.so e depende da presença da rede, o primeiro estágio (autenticação via 802.1X na rede) deve necessariamente ocorrer antes disso. Isto é, deve ocorrer antes do mecanismo builtin:authenticate .

   A partir de uma inspeção casual do binário loginwindow do plugin, parece que ele lida com essa autenticação 802.1X, mas o único mecanismo invocado dentro desse plug-in antes de builtin:authenticate é loginwindow:login . Estou correto em pensar que esse mecanismo não apenas exibe o prompt de login, mas também tenta a autenticação 802.1X? (Se assim for, isso não só parece um pouco desleixado IMHO, mas também sugere que as credenciais de EFI / auto-login não podem ser usadas para autenticação de janela de login do 802.1X.)

Answer 1

1. Do que eu me lembro loginwindow: login é realmente usado em gerar a janela de login da GUI, semelhante ao builtin: policy-banner. Portanto, é lógico que seja gerado antes do restante das ações. Portanto, a janela da GUI é a que é realmente irrelevante / ignorável, não as próprias credenciais.

2. O que exatamente você gostaria de modificar e com qual finalidade? Por exemplo, se você precisar que o plug-in de autorização seja chamado em outras situações, poderá fazê-lo editando auth.db.

Além disso, os subsistemas internos: autenticados devem lidar com a diferenciação entre o 802.1X e a autenticação local.

    

Answer 2

builtin:forward-login,privileged

Encaminha o êxito do login do FileVault para a janela de login do OS X e ignora a necessidade de fazer o login. É como um single sign-on. Eu desabilitei isso no meu ambiente, uma vez que não estava usando o perfil 802.1X que eu tinha configurado. Eu tentaria fazer isso.

OS X: Como desativar o login automático quando o FileVault está habilitado

sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES