Compreendendo a autorização NFSv4 do Kerberized

Question

Artigos como este parecem apontar que as montagens do Kerberizing NFS (v4) não apenas impedem que as máquinas sem um tíquete de serviço Kerberos montem o diretório compartilhado, mas também usam o tíquete Kerberos do usuário para autorizar ações do usuário nos arquivos compartilhados.

cito a parte relevante:

Before NFSv4, security on NFS was pretty much non-existant. You could prevent unauthorized machines from connecting to NFS exports, but had to rely on user ID mappings being the same between systems to use the server's permissions to adequately protect files. Using Kerberos in this manner makes NFS much more secure than it used to be.

O que estou tendo dificuldade em entender é o seguinte cenário, que parece contradizer essa afirmação:

# mount /share #succeeds because I have a service ticket in my keytab
$ klist
klist: No credentials cache found (ticket cache FILE:....)
$ ls /share
ls: cannot access /share: Permission Denied
$ kinit
Password for joe@MYREALM:
$ ls /share
contents of share

Até aí tudo bem, mas quando eu faço isso:

$ kdestroy
$ ls /share
contents of share

O que está acontecendo aqui? Consegui acessar o ponto de montagem do NFS mesmo que eu não tivesse credenciais do Kerberos. Esse comportamento é esperado ou minha montagem está configurada incorretamente?

Info

1. Executando o MIT Kerberos V no Debian Wheezy 7.0

2. Minhas opções de montagem:

   $ grep nfs4 /etc/fstab
   server.myrealm:/nfs_export /share nfs4 sec=krb5,user 0 0
   

3. Meu /etc/exports no servidor:

   /nfs_export *(rw,sync,no_subtree_check,sec=krb5)
   

A página nfs(5) diz que a API do GSS suporta dois tipos adicionais de segurança do Kerberos: krb5i para verificar a integridade dos dados e detectar qualquer violação e krb5p para garantir que todas as chamadas RPC sejam criptografadas por segurança. Eu não acho que habilitar qualquer um deles irá resolver o meu problema.

Editar

De acordo com a sugestão do dawud , experimentei os dois krb5i e krb5p e o comportamento persiste.

Meu problema, mais uma vez, é como ter certeza de que /share está inacessível para quem atualmente não possui um ticket Kerberos? Além disso, posso usar o tíquete Kerberos do usuário para fins de autorização ( i.e. , controle quem pode acessar o que) como o artigo que referenciei parece implicar?

    

Answer 1

Eu tropeço nisso por acidente. Eu percebi que você perguntou isso há séculos, mas queria entrar em sintonia. O comportamento que você está vendo é resultado da maneira como o cliente Linux lida com as credenciais. Depois de encontrar uma credencial de trabalho, ela armazena em cache na memória. Mesmo depois de kdestroy, suas credenciais (ainda válidas) são armazenadas em cache pelo cliente.

Citações do link

"O código do kernel armazena em cache o contexto gssapi que foi negociado usando as credenciais do Kerberos. Destruir as credenciais não destrói o contexto no kernel. Planejamos mudar esse comportamento ao mover para usar o novo suporte ao kernel do conjunto de chaves para armazenar credenciais e contextos ".

Infelizmente, o cliente ainda não usa o suporte de chaveiro.

Espero que ajude ...