文章如这个似乎指出,Kerberizing NFS(v4) 挂载不仅可以防止没有 Kerberos 服务票证的计算机挂载共享目录,而且还使用用户的 Kerberos 票证来授权用户对共享文件的操作。
我引用相关部分:
在 NFSv4 之前,NFS 的安全性几乎不存在。您可以防止未经授权的计算机连接到 NFS 导出,但必须依赖系统之间相同的用户 ID 映射才能使用服务器的权限来充分保护文件。以这种方式使用 Kerberos 使 NFS 比以前更加安全。
我无法理解以下场景,这似乎与此声明相矛盾:
# mount /share #succeeds because I have a service ticket in my keytab
$ klist
klist: No credentials cache found (ticket cache FILE:....)
$ ls /share
ls: cannot access /share: Permission Denied
$ kinit
Password for joe@MYREALM:
$ ls /share
contents of share
到目前为止一切顺利,但是当我这样做时:
$ kdestroy
$ ls /share
contents of share
这里发生了什么事?即使我没有 Kerberos 凭据,我也能够访问 NFS 挂载点。这是预期行为还是我的安装配置错误?
信息
- 在 Debian Wheezy 7.0 上运行 MIT Kerberos V
我的安装选项:
$ grep nfs4 /etc/fstab server.myrealm:/nfs_export /share nfs4 sec=krb5,user 0 0
我
/etc/exports
在服务器上:/nfs_export *(rw,sync,no_subtree_check,sec=krb5)
该nfs(5)
页面表示,GSS API 支持两种额外的 Kerberos 安全性:krb5i
检查数据完整性并检测任何篡改,并krb5p
进一步确保所有 RPC 调用都经过加密以确保安全。我认为启用其中任何一个都不能解决我的问题。
编辑
按照达乌德的建议我尝试了两者krb5i
,并且krb5p
该行为仍然存在。
我的问题又是如何确保/share
当前没有 Kerberos 票证的任何人都无法访问?此外,我可以使用用户的 Kerberos 票证进行授权(IE,控制谁可以访问什么)正如我引用的文章似乎暗示的那样?
答案1
您所看到的行为是 Linux 客户端处理凭据的方式造成的。一旦找到工作凭证,它就会将其缓存在内存中。即使在您 kdestroy 之后,您的(仍然有效的)凭据也会被客户端缓存。
引用自http://www.citi.umich.edu/projects/nfsv4/linux/faq/
内核代码缓存使用 Kerberos 凭据协商的 gssapi 上下文。销毁凭据不会破坏内核中的上下文。我们计划在转而使用新的密钥环内核支持来存储凭据和上下文时更改此行为。
不幸的是,客户端仍然不使用密钥环支持。