Início / computer / Perguntas / 1692126
Accepted
epl
Asked: 2021-12-10 05:24:32 +0800 CST

nfs totalmente sem senha através do kerberos

  • 772

Eu tenho uma pequena rede que inclui um NAS. no qual provisionei, com algum esforço, um servidor Kerberos. O servidor Kerberos permite que os hosts Linux na rede criem montagens NFS seguras. As chaves de serviço criadas no KDC são distribuídas aos hosts apropriados e as montagens são configuradas com segurança Kerberos. As montagens inseguras são bloqueadas pela política configurada no NAS.

Inconvenientemente, os usuários podem acessar arquivos nas montagens somente se tiverem tickets ativos no host do KDC. Esse requisito é restritivo, devido à inconveniência, e ainda mais ao limitar o acesso às montagens por tarefas automatizadas executadas com permissões regulares de usuário.

Nos primeiros dias do NFS, os arquivos em um volume remoto apareciam como locais, começando na inicialização e continuamente por toda a sessão do sistema. O gerenciamento de segurança e identidade são benefícios importantes do Kerberos no NFS, mas exigir que os usuários recebam tíquetes geralmente é desnecessário. Como a distribuição de chaves e o acesso controlado aos hosts evitam o acesso indesejado às montagens NFS, não preciso de tíquetes de usuário.

Idealmente, eu gostaria que os usuários acessassem montagens que tenham segurança Kerberos sem solicitar um tíquete do KDC ou mesmo precisar de um principal registrado nele. Qualquer usuário teria acesso o tempo todo a qualquer arquivo, desde que o acesso não fosse restringido por permissões por arquivo.

Quão próximo desse cenário-alvo é possível por meio das ferramentas existentes?

linux security

1 respostas

  1. Best Answer

    A resposta curta é que o mecanismo de autenticação NFS Kerberos atual (RPCSEC_GSS) não oferece suporte a isso. O principal que está fazendo a chamada é aquele que obtém acesso. Portanto, se você não quiser que os usuários obtenham tíquetes manualmente , precisará fazer com que o host obtenha tíquetes automaticamente para eles.

    No futuro, o protocolo RPCSEC_GSSv3 mais recente pode ter opções para permitir que os hosts representem usuários arbitrários, mas ainda não foi concluído nem implementado.

    Se você deseja permitir que os hosts representem qualquer UID, não precisa do Kerberos - volte para o sec=sysmodo de segurança que era usado "antigamente". Nesse modo, o host literalmente especifica um identificador simbólico do usuário. (As verificações de permissão ainda acontecem, é claro.)

    No final, não há diferença funcional entre permitir que um host represente qualquer usuário via Kerberos (autenticado usando o /etc/krb5.keytab do host), versus permitir que um host represente qualquer usuário por meio de declaração UID básica (autenticado usando o IPsec do host ou chave privada WireGuard ou) – e o último lhe dará um desempenho muito maior do que o GSSAPI pode alcançar.

    No Kerberos, ao usar apenas as ferramentas existentes (sem implementar diretamente algum tipo de autenticação no nível do host para RPC), o mais próximo que você tem é a delegação restrita com transição de protocolo (S4U2Self + S4U2Proxy), onde um serviço tem permissão para obter tickets para outros serviços em nome de um usuário. É comumente usado em ambientes Active Directory, mas também é suportado pelos KDCs do MIT Kerberos (e provavelmente pelos KDCs do Heimdal – o código está lá, graças ao Samba, mas não sei como habilitá-lo no Heimdal).

    Para habilitar isso em um MIT Kerberos KDC, você precisará usar o backend LDAP; o back-end HDB baseado em arquivo não oferece suporte ao armazenamento de campos adicionais.

    1. Defina o ok_to_auth_as_delegatesinalizador principal no principal do host do cliente (pode ser feito por meio do kadmin ou por ORing 0x200000no krbTicketFlagsatributo LDAP).

      kadmin.local modprinc +ok_to_auth_as_delegate host/foo.example.com

    2. Defina o atributo LDAP do principal do cliente krbAllowedToDelegateTopara uma lista de principais de serviço NFS para os quais ele pode criar os tickets falsos. (Um serviço por valor.)

      ldapmodify <<EOF
dn: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,ou=Kerberos,o=Example
add: krbAllowedToDelegateTo
krbAllowedToDelegateTo: nfs/fs1.example.com
-
EOF

    3. Teste se os recursos do S4U funcionam, como root:

      # Acquire host credentials using system keytab
host_cc=FILE:/tmp/krb5cc_host
kinit -c $host_cc -k
klist -c $host_cc

# Acquire NFS tickets on behalf of the user using S4U2Proxy
kvno -c $host_cc -I $user_name -P nfs/fs1.example.com
klist -c $host_cc

# Do the same, but put the tickets in that user's cache
# so that rpc.gssd would be able to find them
user_cc=FILE:/tmp/krb5cc_$(id -u $user)
kvno -c $host_cc -I $user -P nfs/fs1.example.com --out-cache $user_cc
chown $user: $user_cc

    4. Instale o gss-proxy no cliente e edite o incluído nfs-client.confpara usar S4U2Proxy em vez de keytabs de clientes individuais:

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

      Este exemplo é baseado em https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation .

    5. Configure o daemon rpc.gssd do cliente para usar gss-proxy adicionando GSS_USE_PROXY=1ao ambiente:

      # systemctl edit rpc-gssd

[Service]
Environment=GSS_USE_PROXY=1

# systemctl restart rpc-gssd

    Se o Kerberos for usado exclusivamente para NFS e se cada host precisar apenas de um conjunto limitado de usuários, o host poderá armazenar keytabs de cliente (que contêm as chaves derivadas de senha) para esses usuários. Isso é aproximadamente equivalente a armazenar as senhas dos usuários, pois o keytab permite

    • 1

relate perguntas