Acessando o servidor NFS do Kerberized a partir de daemons em servidores de clientes específicos

Question

Eu tenho uma árvore NFS exportada de um servidor de arquivos que é protegido usando o Kerberos e usa LDAP para autenticação e gerenciamento de uid / gid. Tudo funciona muito bem para cada máquina cliente e para cada usuário individual, mas não sei como conceder acesso a partes do compartilhamento para daemons.

Os daemons geralmente são executados com um setuid para uma conta do sistema local, portanto, não há credenciais específicas para eles no servidor. Se eu consigo entrar e me meter com a fonte, geralmente consigo fazer com que eles chamem o kinit com um arquivo keytab para um usuário que existe no kerberos quando eles iniciam, mas isso nem sempre é possível.

Nosso ambiente me proíbe de abrir as portas, tornando-as legíveis para o mundo, ou removendo completamente o Kerberos do NFS.

Eu brinquei com a adição de uma subárvore a /etc/exports com all_squash , anonuid=... e anongid=... set, mas isso só tornou legível para todos os computadores clientes. Precisa estar acessível apenas a uma determinada máquina.

Eu tentei usar o samba, mas temos alguns daemons que têm uma abordagem "NFS ou busto" para trabalhar com compartilhamentos (qualquer coisa envolvendo mercurial, por exemplo).

A maioria dos nossos servidores executa o Ubuntu 10.04 LTS, embora o problema também afete um cliente 12.04 LTS que temos.

Existe uma maneira de conceder ao sistema inteiro um ticket para todo o sistema para um determinado usuário do Kerberos, para que qualquer usuário nesse sistema sempre possa acessar o compartilhamento? Ou há algum outro método para alcançar esse tipo de acesso que eu possa investigar?

    

Answer 1

Uma maneira "adequada" de fazer isso envolve reescrever scripts de init para usar k5start no daemon- keytabs de modo e por daemon. Isso garantirá que o daemon em execução tenha acesso a um cache de credenciais válido enquanto estiver em execução.

Você provavelmente desejará os princípios de estilo daemon / hostname.domain.tld. Eles são mais fáceis de rastrear e mais fáceis de gerenciar para os keytabs. Adicionar uma chave a um keytab incrementa automaticamente o número da versão da chave (KVNO) e randomiza a "senha" para o principal.

    

Answer 2

Se você estiver executando gssproxy, com uma configuração padrão do cliente nfs como:

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

Você pode colocar o keytab do serviço em /var/lib/gssproxy/clients/%UID%.keytab e o gssproxy lidará com a criação dos tickets para você. Isso pode ser preferível ao uso do k5start porque o k5start pode mexer com as transições do SELinux.