Casos de uso para o tipo de cache de credencial do kerberos MEMORY?

Question

Um dos tipos de cache de credenciais oferecidos pelo MIT Kerberos é MEMORY . De acordo com a documentação ela é usada pelo kadmin.

MEMORY caches are for storage of credentials that don’t need to be made available outside of the current process. For example, a memory ccache is used by kadmin to store the administrative ticket used to contact the admin server.

Eu tentei definir default_ccache_name = MEMORY: em /etc/krb5.conf . Depois disso, fiz uma captura de pacotes enquanto emitia o comando kinit . A partir dessa captura, posso ver que um TGT foi obtido com sucesso do KDC. Este bilhete foi então (obviamente) perdido assim que o processo kinit terminou. Além disso, parece que, se forem necessários tickets baseados em memória persistente, pode-se usar o tipo KEYRING ccache.

Quais são os outros casos de uso do tipo de cache de credencial MEMORY?

Suponho que isso não seja útil em um script bash, por exemplo. Quando o script chamar kinit , ele será bifurcado e, após a conclusão, o ticket obtido não será acessível ao pai.

Existe talvez um arquivo de cabeçalho do kerberos que pode ser incluído para manter os tickets obtidos no mesmo espaço de endereço que o resto da sua lógica?

    

Answer 1

A resposta a esta pergunta é exatamente o que foi postulado nos comentários. Do seu código, você pode incluir o cabeçalho krb5.h . Isso lhe dará acesso às funções que compõem a base de código do Kerberos.

Abaixo está um exemplo de brinquedo que é adaptado de a documentação .

#include <string.h>
#include <krb5.h>

int main(void)
{
    krb5_error_code ret;
    krb5_creds creds;
    krb5_principal client_princ = NULL;

    krb5_context context;
    const char* princname = "user@REALM";
    const char* password = "secret";

    krb5_init_context(&context);

    memset(&creds, 0, sizeof(creds));
    ret = krb5_parse_name(context, princname, &client_princ);
    if (ret)
        goto cleanup;
    ret = krb5_get_init_creds_password(context, &creds, client_princ,
                                       password, NULL, NULL, 0, NULL, NULL);
    if (ret)
        goto cleanup;
    ret = krb5_verify_init_creds(context, &creds, NULL, NULL, NULL, NULL);

    /* do things with the ticket (&creds) here */

    cleanup:
    krb5_free_principal(context, client_princ);
    krb5_free_cred_contents(context, &creds);

    return 0;
}

A função krb5_init_context() é o que lê seu arquivo de configuração e honra o tipo MEMORY: ccache. O ticket obtido será armazenado nesse espaço de memória do processo.

Este código, de fato, obtém um TGT. Podemos verificar isso tomando uma captura de pacote enquanto ele é executado. Nós também podemos apenas descarregar a memória deste processo e verificar se o TGT está contido nele.

    

Answer 2

O manual fala sobre kadmin example. Pode ser chamado como um CLI com tickets normais em KEYRING ou em FILE s. A outra possibilidade é executar os comandos interativamente no kerberos "shell". Nesse caso, o ticket é armazenado na memória do processo, onde é "mais seguro" e é automaticamente limpo quando o processo termina.

Da mesma forma, os tickets e operações do kerberos podem ser acessados de outros aplicativos usando os arquivos "header" já mencionados, geralmente usando o chamado GSSAPI ( gssapi.h ). Não responda completamente à sua pergunta, mas é assim que as primitivas do Keberer são acessadas no OpenSSH para acessar o tíquete Kerberos local e autenticar no servidor remoto (nesse caso, o tipo MEMORY não seria útil).