☰

полностью безпарольный nfs через kerberos

tag-icon • tag-icon linux security nas nfs kerberos
полностью безпарольный nfs через kerberos

У меня есть небольшая сеть, включающая NAS, на котором я подготовил, с некоторыми усилиями, сервер Kerberos. Сервер Kerberos позволяет хостам Linux в сети создавать безопасные монтирования NFS. Ключи служб, созданные на KDC, распространяются на соответствующие хосты, а монтирования настраиваются с помощью безопасности Kerberos. Небезопасные монтирования блокируются политикой, настроенной на NAS.

Неудобно, что пользователи могут получить доступ к файлам на монтированиях только при наличии у них активных билетов на хосте от KDC. Это требование является ограничительным из-за неудобства, и тем более из-за ограничения доступа к монтированиям автоматизированными задачами, запущенными с разрешениями обычного пользователя.

В ранние дни NFS файлы на удаленном томе отображались как локальные, начиная с загрузки и непрерывно в течение всего сеанса системы. Безопасность и управление идентификацией являются важными преимуществами Kerberos в NFS, но требование предоставления пользователям билетов часто не является необходимым. Поскольку распределение ключей и контролируемый доступ к хостам предотвращают нежелательный доступ к монтированиям NFS, мне не нужны пользовательские билеты.

В идеале я хотел бы, чтобы пользователи имели доступ к монтированиям, имеющим защиту Kerberos, без запроса билета от KDC или даже без необходимости регистрации принципала на нем. Любой пользователь имел бы доступ в любое время к любому файлу, при условии, что доступ не будет ограничен разрешениями на каждый файл.

Насколько близко к этому целевому сценарию можно приблизиться с помощью существующих инструментов?

решение1

Короткий ответ заключается в том, что текущий механизм аутентификации NFS Kerberos (RPCSEC_GSS) не поддерживает это. Принципал, который делает вызов, — это тот, кто получает доступ. Так что если вы не хотите, чтобы пользователивручнуюполучить билеты, тогда вам нужно будет, чтобы хост автоматически получал билетыдляих.

В будущем новый протокол RPCSEC_GSSv3 может иметь опции, позволяющие хостам выдавать себя за произвольных пользователей, но он еще не завершен и не реализован.

Если вы хотите разрешить хостам выдавать себя за любой UID, то вам вообще не нужен Kerberos — переключитесь обратно в sec=sysрежим безопасности, который использовался «в старые времена». В этом режиме хост буквально может указать символический идентификатор пользователя. (Конечно, проверки разрешений все еще происходят.)

В конце концов, нет никакой функциональной разницы между разрешением хосту выдавать себя за любого пользователя через Kerberos (аутентификация с использованием /etc/krb5.keytab хоста) и разрешением хосту выдавать себя за любого пользователя с помощью базового утверждения UID (аутентификация с использованием закрытого ключа IPsec или WireGuard хоста) — и последний вариант обеспечит вам гораздо более высокую производительность, чем может достичь GSSAPI.

В Kerberos, при использовании только существующих инструментов (без прямой реализации какой-либо аутентификации на уровне хоста для RPC), наиболее близким к этому являетсяограниченное делегирование с переходом протокола(S4U2Self + S4U2Proxy), где службе разрешено получать билеты на определенные другие службы от имени пользователя. Это обычно используется в средах Active Directory, но также поддерживается MIT Kerberos KDC (ивероятноHeimdal KDCs – код есть, спасибо Samba, но я не знаю, как включить его в Heimdal).

Чтобы включить эту функцию в MIT Kerberos KDC, вам необходимо использовать бэкэнд LDAP; файловый бэкэнд HDB не поддерживает хранение дополнительных полей.

  1. Установите ok_to_auth_as_delegateфлаг принципала на принципале хоста клиента (это можно сделать через kadmin или с помощью операции OR 0x200000в krbTicketFlagsатрибуте LDAP).

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

  2. Установите атрибут LDAP принципала клиента krbAllowedToDelegateToна список принципалов служб NFS, для которых он может создавать поддельные билеты. (Одна служба на значение.)

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

  3. Проверьте работу функций S4U с правами 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. Установитьgss-проксина клиенте и отредактируйте его include, nfs-client.confчтобы использовать S4U2Proxy вместо отдельных клиентских keytab:

    [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

    Этот пример основан наhttps://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#имитация-пользователя-через-ограниченное-делегирование.

  5. Настройте клиентаrpc.gssdдемон для использования gss-proxy, добавив GSS_USE_PROXY=1в среду:

    # systemctl edit rpc-gssd

[Service]
Environment=GSS_USE_PROXY=1

# systemctl restart rpc-gssd

Если Kerberos используется исключительно для NFS и если каждому хосту нужен только ограниченный набор пользователей, то хост может хранитьклиентские клавиши(которые хранят ключи, полученные из паролей) для этих пользователей. Это примерно эквивалентно хранению паролей пользователей, поскольку keytab позволяет

Связанный контент