Я установил kerberos с NFS, и он работает нормально.
Однако, похоже, есть проблема с тем, как это работает, любой клиент Kerberos, похоже, может получить доступ к любому каталогу (если они выберут правильный ip)
На сервере NFS (192.168.1.12):
$ exportfs -v
/data/mail 192.168.1.13(rw,wdelay,root_squash,no_subtree_check,mountpoint,sec=krb5,rw,secure,no_all_squash)
/data/web 192.168.1.14(rw,wdelay,root_squash,no_subtree_check,mountpoint,sec=krb5,rw,secure,no_all_squash)
Я размещаю почту и Интернет на разных серверах. Идея состоит в том, что если один будет скомпрометирован, злоумышленник не получит доступа к другому.
Итак, я установил nfs и kerberos, поэтому mail.example.com (.13) может монтировать / data / mail, а web.example.com (.14) может монтировать / data / web, и ни один из них не может монтировать другой. Все идет нормально. Однако затем я изменил IP-адрес web.example.com на .13 и смог смонтировать / data / mail.
Вот как это выглядит на web.example.com:
ktutil: rkt /etc/krb5.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 2 nfs/web.example.com@example.com
2 2 nfs/web.example.com@example.com
И на mail.example.com:
ktutil: rkt /etc/krb5.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 2 nfs/mail.example.com@example.com
2 2 nfs/mail.example.com@example.com
Вот как выглядит / etc / hosts на сервере NFS:
192.168.1.11 kdc.example.com
192.168.1.13 mail.example.com
192.168.1.14 web.example.com
Я ожидал, что, поскольку у web.example.com есть тикет, который идентифицирует его как web.example.com, он не сможет смонтировать / data / mail, даже если ему понадобится ip mail.example.com. Однако кажется, что пока у вас есть действующий билет Kerberos и правильный IP-адрес, вы можете смонтировать любой каталог. Для меня в этом нет смысла использовать Kerberos, поскольку я не ожидаю, что к этой сети кто-то подключится. Это действительно единственная угроза, от которой защищает Kerberos с NFS, или я что-то неправильно сконфигурировал?
sec=krb5 не останавливает установку действующего билета, но это не его работа.
Это предотвратит доступ к файлам неавторизованных клиентов (на основе uid / gid, а не ip). Предполагая, что вы совершили такую глупую вещь, как root@EXAMPLE.COM, вам может потребоваться ужесточить права доступа к файлам.
Даже с root_squash удаленный корень может изменить свой euid на что-то с надлежащим доступом, насколько sec=sys обеспокоен. То же самое не относится ни к одному из вариантов krb5. Конечно, это все не для того, если файлы / каталоги имеют разрешения, позволяющие другим, например. 775 позволит читать, а 770 нет.
Боковое примечание: вы должны использовать хотя бы использовать sec=krb5i, если не sec=krb5p.