在使用 ecryptfs 首次登录之前以编程方式获取密码?

在使用 ecryptfs 首次登录之前以编程方式获取密码?

我们正在学习/试验 eCryptfs (Ubuntu Server 10.04)。我们正尝试使用我们可以执行的 bash 脚本以编程方式在我们的服务器上设置用户,包括加密他们的“/home”。

我们试图避免必须登录新帐户才能生成 ecryptfs 密码。一旦我们这样做了,我们就可以通过另一个帐户的 bash 恢复密码,但希望避免“手动”登录步骤。

我们应该提到,这是一个面向互联网的服务器,我们正在尽力“锁定它”,我们正在试图阻止用户“随意”更改密码,因此将要求他们提出密码更改请求,加密的目的是让用户无法访问彼此的帐户(还有其他也许更好的方法来满足这一需求 - 包括只是“隐藏”他们的 /home,尽管除了 ssh 之外,加密也会强制登录)。

那么,有没有办法编写一个登录脚本(我们在谷歌上看到过帖子说这是不可能的)来代替手动登录,以便创建密码,然后我们可以使用 ecryptfs-unwrap-passphrase 捕获并记录它。

答案1

我无法确定加密家庭设置脚本的当前实现是否允许您执行您要执行的操作。其他人将不得不帮助您完成此操作。

但是,我确实想指出,您对 eCryptfs 的使用有点误导。eCryptfs 并非真正旨在提供一种增强的访问控制形式,并且依赖它来实现这一点存在一些问题。

如果恶意用户试图访问其他用户的数据,并且该用户的加密主目录已挂载(这意味着加密密钥位于内核密钥环中),那么 eCryptfs 实际上不会提供任何比常规 DAC 权限更多的东西。如果攻击者可以绕过 DAC,那么他很可能利用了某种类型的内核漏洞,如果此时加密密钥已加载到内核密钥环中,那么 eCryptfs 不会提供任何保护。

请注意,对于在攻击时未安装其主目录的用户,有一些有用的保护,但您必须确定用户在任何给定时间安装其主目录的可能性是否更大或更小。

还请注意,如果您计划备份加密数据,那么按用户加密备份将为您带来好处。管理员将无法轻松访问数据,而您也不必再为磁带驱动器放错位置而夜不能寐。

我并不是要阻止您使用 eCryptfs,但我确实希望您了解使用文件加密时增加的复杂性和略微的性能下降会带来什么后果。

相关内容