☰

nfs completamente sin contraseña a través de kerberos

tag-icon • tag-icon linux security nas nfs kerberos
nfs completamente sin contraseña a través de kerberos

Tengo una red pequeña que incluye un NAS. en el que aprovisioné, con cierto esfuerzo, un servidor Kerberos. El servidor Kerberos permite a los hosts Linux de la red crear montajes NFS seguros. Las claves de servicio creadas en el KDC se distribuyen a los hosts apropiados y los montajes se configuran con seguridad Kerberos. Los montajes inseguros están bloqueados por la política configurada en el NAS.

Lo inconveniente es que los usuarios pueden acceder a los archivos en los soportes sólo si tienen tickets activos en el host del KDC. Este requisito es restrictivo, debido a las molestias, y más aún al limitar el acceso a los montajes por parte de tareas automatizadas que se ejecutan con permisos de usuario habituales.

En los primeros días de NFS, los archivos en un volumen remoto aparecían como locales, comenzando en el arranque y de forma continua durante toda la sesión del sistema. La seguridad y la gestión de identidades son beneficios importantes de Kerberos en NFS, pero a menudo es innecesario exigir a los usuarios que reciban tickets. Dado que la distribución de claves y el acceso controlado a los hosts evitan el acceso no deseado a los montajes NFS, no necesito tickets de usuario.

Idealmente, me gustaría que los usuarios accedan a montajes que tengan seguridad Kerberos sin solicitar un ticket del KDC, o incluso sin necesitar un principal registrado en él. Cualquier usuario tendría acceso en todo momento a cualquier archivo, siempre que el acceso no esté restringido por permisos por archivo.

¿Qué tan cerca de este escenario objetivo es posible a través de las herramientas existentes?

Respuesta1

La respuesta corta es que el mecanismo de autenticación NFS Kerberos actual (RPCSEC_GSS) no lo admite. El director que hace la llamada es el que obtiene acceso. Entonces, si no quieres que los usuariosa manoobtener boletos, entonces necesitarás que el anfitrión obtenga boletos automáticamenteparaa ellos.

En el futuro, el protocolo RPCSEC_GSSv3 más nuevo podría tener opciones para permitir que los hosts se hagan pasar por usuarios arbitrarios, pero aún no se ha terminado ni se ha implementado.

Si desea permitir que los hosts se hagan pasar por cualquier UID, entonces no necesita Kerberos en absoluto; vuelva al sec=sysmodo de seguridad que se usaba "en los viejos tiempos". En este modo, el anfitrión literalmente especifica un identificador simbólico del usuario. (Por supuesto, todavía se realizan comprobaciones de permisos).

Al final, no hay diferencia funcional entre permitir que un host se haga pasar por cualquier usuario a través de Kerberos (autenticado usando el /etc/krb5.keytab del host) y permitir que un host se haga pasar por cualquier usuario a través de un reclamo UID básico (autenticado usando el IPsec del host). o clave privada WireGuard o) – y este último le brindará un rendimiento mucho mayor que el que GSSAPI puede lograr.

Dentro de Kerberos, cuando se utilizan únicamente herramientas existentes (sin implementar directamente algún tipo de autenticación a nivel de host para RPC), lo más parecido que se tiene esdelegación restringida con transición de protocolo(S4U2Self + S4U2Proxy), donde un servicio puede obtener entradas para otros servicios específicos en nombre de un usuario. Se utiliza habitualmente en entornos Active Directory, pero también es compatible con los KDC Kerberos del MIT (yprobablementeKDC de Heimdal: el código está ahí, gracias a Samba, pero no sé cómo habilitarlo en Heimdal).

Para habilitar esto en un KDC MIT Kerberos, necesitará utilizar el backend LDAP; el backend HDB basado en archivos no admite el almacenamiento de campos adicionales.

  1. Establezca el ok_to_auth_as_delegateindicador principal en el principal del host del cliente (se puede hacer a través de kadmin o mediante OR 0x200000en el krbTicketFlagsatributo LDAP).

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

  2. Establezca el krbAllowedToDelegateToatributo LDAP de la entidad de seguridad del cliente en una lista de entidades de servicio NFS para las que puede crear tickets falsos. (Un servicio 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. Pruebe si las funciones de S4U funcionan, 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. Instalarproxy-gssen el cliente y edite lo incluido nfs-client.confpara usar S4U2Proxy en lugar de las pestañas de claves del cliente individuales:

    [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 ejemplo se basa enhttps://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation.

  5. Configurar el clienterpc.gssddemonio para usar gss-proxy agregando GSS_USE_PROXY=1al entorno:

    # systemctl edit rpc-gssd

[Service]
Environment=GSS_USE_PROXY=1

# systemctl restart rpc-gssd

Si Kerberos se utiliza exclusivamente para NFS y cada host sólo necesita un conjunto limitado de usuarios, entonces el host puede almacenarpestañas de claves del cliente(que contienen las claves derivadas de la contraseña) para esos usuarios. Esto es más o menos equivalente a almacenar las contraseñas de los usuarios, ya que la tabla de claves lo permite.

información relacionada