如果我从gnome-keyring中删除密码,在后台会发生什么?未加密的ssh密钥或密码在文件系统中可读吗?

scon00

我正在运行debian 10,xfce,gnome-keyring,ssh-agent,LUKS分区。

我使用gnome-keyring的原因是因为我不想在重新启动后输入ssh密钥密码。这是因为周围有很多闭路电视摄像机。恐怕某种秘密的闭路电视摄像机会记录我键入的内容。我总是避免输入密码,并尽量减少输入时间。

在当前设置下,我至少需要输入两个密码。一个用于LUKS分区,另一个用于lightdm中的系统登录。

今天,我正在考虑减少一个密码要求并使系统自动登录,因此不再需要输入系统用户登录密码。我认为这仍然与以前处于相同的安全级别,因为LUKS分区加密仍然存在。(或不太安全,但使用LUKS仍然安全)

启用自动登录后,我发现gnome密钥环已不再自动解锁。如果要使用当前设置解锁,则必须再次输入解锁密码,这是我要避免的第二个密码。

通过搜索,我发现我可以简单地从海马中的gnome密钥环中删除解锁密码,因此可以使用自动登录对其进行解锁。

以上是我目前情况的详细故事。所以这是问题。我不知道如果我从gnome密钥环中删除解锁密码,在后台会发生什么。

我之所以使用gnome密钥环,是因为我不希望系统中的任何正在运行的程序都可以直接从文件系统访问ssh私钥~/.ssh/id_rsa有人可能会争辩说程序可能仍会从内存中获取密钥。我真的不关心它如何工作,只要它可以提高某种安全性即可。我可以,只要未加密的ssh-key不存储在文件系统中的某个位置即可。恐怕从gnome-keyring中删除密码会使未加密的文件以纯文本格式存储在文件系统中。从gnome密钥环中删除密码是否会对存储(文件系统)的观点有所不同?

我并不在乎没有用于解锁密钥环的密码,因为我拥有LUKS分区加密,除非人们知道我的LUKS密码,否则人们将无法使用密钥环。但是,如果删除了钥匙圈密码,我确实在乎是否有任何正在运行的程序可以直接从文件系统访问某些纯文本键。

我希望我已经在这个问题上明确表示了自己,并非常感谢您的帮助。

用户名

我不知道如果我从gnome密钥环中删除解锁密码,在后台会发生什么

密钥环的密码不能直接用作SSH密钥的密码。它仅用于加密单个文件-位于的数据库~/.local/share/keyrings/login.keyring

您所有的SSH密钥和其他文件都将使用其原始密码进行加密。

(较旧的系统可能有两个单独的密钥环“ login”和“ default”。在这种情况下,您只需解密“ login”密钥环,因为它还存储了所有其他密钥环的密码。)

我并不在乎没有用于解锁密钥环的密码,因为我拥有LUKS分区加密,除非人们知道我的LUKS密码,否则人们将无法使用密钥环。但是,如果删除了钥匙圈密码,我确实在乎是否有任何正在运行的程序可以直接从文件系统访问某些纯文本键。

我对此有两个不同的答案,这两个都是坏消息:

  • 第一个问题是您的密码是GNOME Keyring可以使用的唯一加密密钥源如果删除密码,则GNOME密钥环将被迫完全不加密地存储其密码数据库。(它甚至会keyrings/login.keyring从二进制数据库转换为文本格式,以使其非常清楚。)

    这不会直接更改与您的SSH密钥文件有关的任何内容:如果以前对其进行过加密,则以后仍将对其进行加密。但是它们的加密密码以及所有其他密码和密码(甚至可能是您的GnuPG密钥密码)将以纯文本格式存储在GNOME Keyring的数据库中。

    因此,如果您最关心的是直接文件系统访问,那么可以,您的密钥可以被窃取-攻击者现在只需要窃取一个文件即可。

  • 第二个问题是...第一个问题甚至都没有关系,因为常规应用程序不仅限于访问自己的密钥环条目。只要您的GNOME密钥环已解锁,任何非Flatpak程序都可以使用官方API查询存储在密钥环中的任何条目并获取所需的任何存储密码,无需监听内存或其他技巧。从CLI尝试一下:

    secret-tool search --all xdg:schema org.freedesktop.Secret.Generic
    secret-tool search --all xdg:schema org.gnupg.Passphrase
    

    因此,密钥环密码仅可用于防止脱机攻击(在使用LUKS时是多余的)–从未用于防止正在运行的系统上的恶意软件。


以下是一些提高安全性的想法(主要是在您防范通用漏洞利用/病毒/蠕虫而不是针对性攻击的前提下):

  • 如果可能,通过Flatpak安装应用程序。默认情况下,它们被限制在一个容器中,该容器无法访问您的文件也无法访问您的密钥环。

  • Flatpak中未提供的应用程序可以在其他UID下运行(例如,通过Xvnc或Xephyr使它们显示在主屏幕上)。有些人以这种方式运行Firefox,因此有很多教程。

  • SSH密钥只能加载ssh-agent中,而不能从中提取出来结合这一事实,可能有可能通过一种方式来配置AppArmor或SELinux,以防止“ ssh-add”以外的任何进程都无法访问~/.ssh/id_*文件。

  • 您可以将RSA或ECDSA密钥存储在专用的硬件令牌中,例如,笔记本电脑的TPM芯片(如果有的话)。(如果没有,那么支持PIV / OpenPGP的Yubikey可以做不同的事情。)就像ssh-agent本身一样,令牌将不允许您找回原始密钥-它仅提供签名操作。

    (理论上,FIDO / U2F令牌的工作方式相同,但它们仅允许以非常特定的格式签名数据,因此它们不能用作普通的SSH密钥。最新的OpenSSH版本可以使用具有新sk-*密钥类型的FIDO令牌,但您的所有服务器也必须先升级以支持它们。)

  • 缺乏硬件支持,您可以将ssh-agent与SoftHSM虚拟智能卡结合使用,后者仍然是软件,但是很容易使其在专用UID下运行。这样,您的主UID将无权访问SoftHSM的数据库,并且只能执行其PKCS#11模块允许的操作。

  • Qubes操作系统,我猜呢?

本文收集自互联网,转载请注明来源。

如有侵权,请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

Related 相关文章

热门标签

归档