Privilégios ao fazer o sudo para outro usuário do domínio

Question

Suponha que eu tenha um domínio corporativo mydomain usando o MS Active Directory. No domínio eu tenho os usuários myuser e youruser . Agora, em uma máquina Ubuntu específica mymachine , myuser tem direitos sudo e sudo su youruser (ou sudo -u youruser sh ). Como myuser tem a configuração necessária dos sudoers, ele não precisa digitar a senha do seu usuário, e efetivamente se tornará seu usuário na máquina .

1. Que tipo de youruser privilégios terão myuser neste momento? Obviamente, se youruser também tiver um diretório inicial na máquina, myuser agora poderá acessá-lo e ler seus arquivos locais privados. Mas o que acontecerá se você tentar acessar um recurso de domínio de rede usando kerberos, samba etc? Eu acho que uma vez que ele nunca digitou a senha de youruser ele não é autenticado como usuário de domínio, não tem um ticket kerberos etc. Então, se há um serviço de rede que verifica as associações de grupo para seu ID de usuário, isso também falhará? Como é que isso funciona? Ele é considerado um usuário diferente, digamos, mymachine\youruser em oposição a mydomain\youruser ?

2. Suponha que haja um serviço da Web em execução como um daemon na máquina, usando um usuário de domínio dedicado myserviceuser . Se esse serviço da Web precisar acessar recursos de rede, ou seja, autenticar com o Kerberos, como o daemon deve ser configurado, por exemplo, a partir de um script iniciante? Normalmente, você o inicia usando algo como sudo -u myserviceuser <cmd> , mas, dadas as suposições acima, isso concederá ao serviço da Web qualquer direito de acessar os recursos da rede? A senha desse usuário não deve ser inserida em algum lugar?

Answer 1

Não há documentação clara o suficiente sobre essas coisas IMO.

1. Você tem razão - se um serviço estiver protegido por kerberos, o su / sudo não é suficiente para ignorar a autorização necessária (A MENOS que o usuário de destino tenha um ticket em cache porque está conectado no momento ou um keytab). A maioria dos recursos (por exemplo, sistema de arquivos local) depende de um número de usuário e número de identificação para identificar um usuário, e pode ser ignorada pelo acesso root / sudo

2. Este é um divertido que eu estou lidando com atualmente no trabalho. Digamos que uma conta de serviço apache precise acessar um compartilhamento NFS kerberizado. Você precisa exportar um keytab para o apache para o sistema de arquivos local e a fonte que quando o serviço for iniciado, renovando periodicamente seu ticket via talvez cron. RHEL7 tem o gssproxy, que parece simplificar isso, mas ainda não cheguei a esse ponto.

Um keytab é efetivamente uma credencial salva. Se alguém puder acessá-lo, ele poderá se passar por esse usuário. Exportar um novo keytab no IPA e no AD altera a senha da conta.

O kerberos da Microsoft é um pouco diferente, mas a maioria das regras ainda se aplica.

    

Answer 2

Estou em uma situação semelhante com os diretórios iniciais do autofs nos diretórios do Kerberized NFSv4:

• Se eu estou vindo de outra máquina kerberizada, posso SSH para a máquina de destino com um TGT encaminhado e minha conta na máquina de destino efetua login normalmente com meu diretório pessoal montado automaticamente.
• Se eu não estiver vindo de outra máquina kerberizada, posso (sujeito à ACL local) efetuar login com uma senha nessa máquina e fazer com que o PAM gere um ticket. O diretório inicial montado automaticamente também aparece nesta situação.
• Não consigo fazer login nesta máquina se depender da conta ter uma entrada em ~/.ssh/authorized_keys porque o diretório inicial está inacessível para o daemon SSH no destino. Ele não está inacessível porque está desmontado, mas é inacessível porque o daemon SSH não tem o TGT para acessar o diretório inicial que contém o arquivo authorized_keys .
• Quando obtiver acesso a uma máquina, independentemente de sudo permissões, não posso sudo su para a conta de outro usuário sem que seu diretório pessoal fique inacessível - novamente, não tenho o TGT.
• Nessa máquina, eu posso su para sua conta e tenho seu diretório home disponível no login se eu tiver sua senha, porque o login através de su passa pelo PAM e isso me dá uma TGT que permitirá que o automount seja bem-sucedido.
• Nas arquiteturas em que o TGT é armazenado em um armazenamento de chaves acessível (como um conjunto de chaves do sistema), o TGT não é apagado pelo logoff, a menos que se faça um kdestroy explícito. Agora posso sudo su para a conta desse usuário e o diretório inicial do automount será bem-sucedido.

O tópico comum aqui é que o TGT não está acessível a menos que um ticket encaminhado seja transferido de outra máquina ou o usuário tenha a senha para obter o ticket com alguma forma de login ou kinit .

Permitindo que as contas de serviço ocasionalmente hospedem usuários (por exemplo, para centralização de configuração complexa como ~/.kube/ ), é insuficiente colocar um keytab no diretório de conta pela mesma razão que authorized_keys não funciona. Também não é suficiente depender de tickets com um longo tempo de vida e tarefas cron para reabastecer um keychain do sistema porque uma reinicialização limparia o keychain e ficaria indisponível até a próxima invocação do cron (o que provavelmente seria algum tempo). Também é uma bagunça para configurar o cron assim em um cluster de máquinas.