NFS/Kerberosのソースを表示

[[Category:ネットワーク共有]]
Kerberos は NFS に利用可能な数少ないセキュリティメカニズムの一つです。Kerberos は強力なユーザー認証とデータ暗号化を提供し、NFSv4 を使用することでクライアントとサーバー間の UIDs/GIDs の一致が不要になります。

Kerberos には NFSv4 が推奨されます。NFSv3 で Kerberos を有効にすることは可能ですが、補助的な NFSv3 プロトコル（例えば「マウント」プロトコル）がセキュアでないため、100% のカバレッジは提供されません。また、NFSv3 には idmapping がないため、Kerberos の使用性が大幅に低下します。

== 前提条件 ==

Kerberos は '''KDC''' （Key Distribution Center）サービスがどこかで動作している必要があります。MIT Kerberos （{{Pkg|krb5}}）に付属する {{ic|krb5-kdc.service}} は、Active Directory や FreeIPA のような複雑さが必要ない小規模設定に適しています。2 番目のオプションは Heimdal で、一部の BSD や Arch 上の {{AUR|heimdal}} で見つかります。

Kerberos と共に NFSv4 の '''idmapping''' がとても重要になります。サーバーとクライアントはどちらも同じ idmapping ドメインを設定している必要があります：

{{hc|/etc/idmapd.conf|2=
[General]
Domain = example.com
}}

== Server configuration ==

Each NFS server needs a Kerberos principal for {{ic|nfs/''server.fqdn''}} to be created on the KDC, and its keys added to the server's {{ic|/etc/krb5.keytab}}. 

{{Note|
{{Expansion|Why?}}
It is recommended to ''also'' have the standard {{ic|host/}} principal there as well, for other purposes.
}}

 fileserv# kadmin -p frob/admin
 Password for frob/admin@EXAMPLE.COM: *********
 kadmin:  addprinc -nokey nfs/fs.example.com
 kadmin:  ktadd nfs/fs.example.com

{{ic|gssproxy.service}} must be [[enable]]d and [[start]]ed on the server. 

{{Tip|Earlier systems used {{ic|rpc.svcgssd}}, but it is no longer present in modern nfs-utils and has been fully superseded by gssproxy.}}

gssproxy comes pre-configured with NFS server support (the {{ic|/etc/gssproxy/24-nfs-server.conf}} file is part of the standard package) and does not need any tweaking, other than placing the NFS service keytab in the standard location.

Your {{ic|/etc/exports}} should offer the Kerberos authentication flavors in the {{ic|1=sec=}} option:

 /home    *(rw,sec=krb5p)
 /usr     10.147.0.0/16(rw,sec=krb5p:krb5i:krb5:sys) *(rw,sec=krb5p)

{{Note|Do not use the obsolete {{ic|gss/krb5p(...)}} syntax. It still works, but you should not be using it anymore.}}

The available flavors are:

* {{ic|krb5p}} provides 'privacy' (Kerberos-based encryption). It is sufficiently secure to be used over Internet, but might provide poor throughput over a LAN – consider using {{ic|krb5}} inside RPC-with-TLS instead.
* {{ic|krb5i}} provides 'integrity' (Kerberos-based MAC) but ''not'' encryption. It might be useful for serving static data as it still protects against packet tampering.
* {{ic|krb5}} provides ''only'' authentication, without data integrity or encryption. It is a good choice if you have RPC-over-TLS enabled via {{ic|1=xprtsec=}} ''or'' if Kerberos is being run over an otherwise "secure" LAN (e.g. over a WireGuard tunnel), but certainly not in the clear over public networks.
* {{ic|sys}} is the traditional UID-based (non-Kerberos) NFS security mode.

== Client configuration ==

In addition to users, each NFS client should have a ''machine'' Kerberos principal in {{ic|/etc/krb5.keytab}}, which will be used in situations where user Kerberos tickets are not yet available – in particular, it will be needed to actually mount the filesystem at boot time before any users have logged in yet (or if mounting is done via autofs). More generally, all operations done "as root" will be authenticated as the machine principal.

{{Tip|The machine identity is also mandatory for some internal NFS operations if NFSv4.0 or NFSv4.1 are used, although no longer mandatory in NFSv4.2.}}

Unlike in the server case, the client machine does not need an {{ic|nfs/}} principal specifically – it is enough to have the generic {{ic|host/''the.fqdn''}} principal. (See the rpc.gssd manual page for what it looks for.)

The client must have {{ic|rpc-gssd.service}} active (i.e. the {{ic|rpc.gssd}} daemon).

Options used when mounting the filesystems are very similar to the options used in {{ic|/etc/exports}}; you can specify one or more flavors using the {{ic|1=sec=}} option. Although the client will automatically use the strongest mode offered, it is nevertheless recommended to explicitly require e.g. {{ic|1=sec=krb5p}} to prevent downgrade attacks.

Once the filesystem has been mounted, root may already access it (using the machine's Kerberos credentials), but '''every''' non-root user needs their own Kerberos tickets to be present. This means either having the user manually run {{ic|kinit}} for themselves, or setting up {{Pkg|pam-krb5}} to acquire tickets during login (which only works for password-based logins), or using {{ic|gssproxy}} or {{man|1|k5start|url=https://manned.org/k5start.1}} (from {{AUR|kstart}}) to acquire tickets from a keytab file. 

{{Tip|You will likely need to set up k5start to ''renew'' tickets as they expire a few hours after being acquired.}}