Compreendendo o getlogin ()

Question

Eu acho que a iteração anterior desta questão foi um pouco como uma bomba de perguntas, de modo que possam ter desviado as pessoas para ele (a ponto de quase ser sinalizado para remoção), então vou começar uma nova que espero que as pessoas possam ter um tempo mais fácil.

Basicamente, meu interesse geral está em entender logname e getlogin() no que se refere a trilhas de auditoria. Ele se divide assim:

1) Meu entendimento é que logname e getlogin() exibem os auid que seriam / serão exibidos nos registros de auditoria da sessão. Isso está correto? Eu sei que auid é um atributo de processo imutável, mas eu estava interessado em saber se os dois são necessariamente os mesmos ou normalmente são os mesmos. Isso me ajudaria a escrever scripts / programas auxiliares que podem tomar decisões de controle de acesso com base na identidade original do usuário, em vez de apenas quem eles são no momento ou uma variável ambiental mutável.

2) Eu ainda não entendo como a exploração de CVE 2003-0388 era mostrado para funcionar. Se alguém pudesse explicar isso para mim, seria ótimo.

Meu principal interesse é com o ponto # 1, no entanto.

    

Answer 1

getlogin() e logname (que apenas chama getlogin() ) obtém o nome de usuário logado procurando pelo tty atual em utmp e informando o nome de login encontrado no registro utmp . A razão pela qual eles fazem isso é que eles são projetados para trabalhar em sistemas onde vários nomes de usuários podem mapear para o mesmo uid (uma prática geralmente desaprovada, mas às vezes usada para criar múltiplas contas raiz ou diferentes nomes de login que iniciam shells customizados, mas todos mapeiam para mesmo uid subjacente). Quando usado com essas contas, getpwuid(getuid()) reportará apenas a primeira correspondência do banco de dados passwd, enquanto getlogin() encontrará a que realmente foi usada para efetuar login.

No entanto, como essa função depende do conteúdo de um arquivo gravável, ela não é digna do mesmo nível de confiança que getpwuid(getuid()) . É verdade que apenas processos privilegiados devem ser capazes de escrever utmp , mas existem alguns programas "extras" que são frequentemente configurados para serem capazes de escrevê-lo (geralmente sendo setgid- utmp ) como a tela GNU e você pode Não quero confiar naqueles. Eu sei que historicamente em alguns sistemas SysV eu costumava gerenciar, utmp estava propenso a se corromper ocasionalmente.

    

Answer 2

Como @Celada apontou, logname e getlogin() dependem de /var/run/utmp , o que os coloca em confiabilidade de nível médio (é um arquivo regular em vez de algo que é necessariamente regenerado com reinicializações, diferente das estruturas de kernel, então há uma pequena possibilidade de contaminação se eles puderem inicializar a partir do CD ou algo assim, então o que não poderia comprometer se eles fizessem isso?). Há esperança escondida à vista de todos. Eu tinha intencionalmente ignorado /proc/$$/loginuid até este ponto porque era de propriedade do usuário invocador e o bit gravável foi definido para o proprietário, então imaginei que era principalmente apenas uma conveniência e não um mecanismo de segurança. Parece que essa suposição estava incorreta. Aqui está o texto descritivo para um patch de kernel apresentado no final de 2011:

At the moment we allow tasks to set their loginuid if they have CAP_AUDIT_CONTROL. In reality we want tasks to set the loginuid when they log in and it be impossible to ever reset. We had to make it mutable even after it was once set (with the CAP) because on update and admin might have to restart sshd. Now sshd would get his loginuid and the next user which logged in using ssh would not be able to set his loginuid.

Systemd has changed how userspace works and allowed us to make the kernel work the way it should. With systemd users (even admins) are not supposed to restart services directly. The system will restart the service for them. Thus since systemd is going to loginuid==-1, sshd would get -1, and sshd would be allowed to set a new loginuid without special permissions.

If an admin in this system were to manually start an sshd he is inserting himself into the system chain of trust and thus, logically, it's his loginuid that should be used!

Então, é listado como gravável pelo usuário? Sim. O usuário pode realmente mudar isso? Somente se eles são root ou possuem CAP_AUDIT_CONTROL (o que provavelmente não é um monte de pessoas). A solução mais segura que posso encontrar é extrair isso de /proc/$$/loginuid (se estiver escrevendo um script de shell ou na linha de comando) ou audit_getloginuid() de um programa.