存储 Linux 守护进程所需的密码
我已经编写了一个 Linux 守护进程，它将（并且必须）以 root 身份运行。 当它运行时，不一定有人登录，因为它是由 cron 启动的。 该守护进程在连接时需要存储一些 url、uid 和密码 到其他服务器（例如 dropbox、google、windows 服务器等）。
问：存储这些密码的*最佳*位置和方法是什么。
我无法存储哈希值，因为我需要原始 url/uid/pwd 来连接 远程服务。
我只能看到两个选项：
a) gnome-keyring-daemon
据我所知，这需要登录的用户/会话。我尝试过从我的守护进程（作为 root）启动它，收集返回的环境变量并尝试连接到它。到目前为止，这已经失败了。
b) root 拥有的只读文件。
也可以使用（例如）hostid 进行加密，但底部 问题是这种方法依赖于默默无闻和根访问。
还有其他选择吗？
I have written a linux daemon that will be (and must be) running as root.
When it runs, there will not necessarily be anyone logged in as it is started by cron.
That daemon needs to store some urls, uids and passwords as it connects
to other servers (such as dropbox, google, windows servers etc).
Q: What is the *best* place and method to store those passwords.
I can't store hashes as I need the original url/uid/pwd to connect to
the remote services.
There are only two options that I can see:
a) gnome-keyring-daemon
As far as I can tell, this requires a logged in user/session. I have experimented with starting it from my daemon (as root), collecting the returned environment variables and attempting to connect to it. So far this has failed.
b) a read-only file owned by root.
This could also be encrypted using (for example) the hostid, but the bottom
line is that this approach relies on obscurity and root access.
Are there other options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
root 拥有的只读文件几乎是推荐的解决方案：openssh 等重要服务使用该选项。
A read-only file owned by root is pretty much the recommended solution: important services such as openssh use that option.
我多次遇到这个问题，因为人们经常对企业安全建议感到困惑。
当必须为 SSL 实施客户端证书身份验证并阅读“不允许自签名证书”时，人们通常会感到困惑，因为拥有由任何外部机构签名的您自己的 CA 证书不会添加任何内容。
人们还对使用加盐哈希算法存储用户凭据的建议感到困惑，因为需要存储守护程序访问数据库服务器或消息代理等服务的凭据。
我总是看到一种幼稚的解决方案，即使用以纯文本形式存储在软件中其他任何位置的密钥密码来加密凭据，这只会给系统管理员带来问题，但不会给入侵者带来问题。不久前，我看到软件开发人员需要对生成的密钥进行哈希处理，将该哈希值存储在文本文件中，并使用该哈希字符串作为密钥来加密/解密包含凭据的文件，架构师很不高兴，直到实际的密钥是看起来像散列密码的字符串。你能相信吗？
您不能依赖守护进程的密钥环/钥匙串，因为守护进程不应该代表用户进行身份验证，如果它们模拟用户，那么它们应该是代理，并且应该使用每个操作系统环境上可用的密钥环/钥匙串。
I faced this problem several times cause because people often gets confused with enterprise security recommendations.
People usually gets confused when having to implement a client certificate authentication for SSL and read the NO SELF-SIGNED CERTIFICATES ALLOWED because having the your own CA certificate signed by any external authority would not add anything.
People also gets confused with the recommendation to STORE USERS CREDENTIAL USING A SALTED HASH ALGORITHM with the need to store credentials for a daemon to access services like database servers or message brokers.
I always see the naïve solution to encrypt credentials with the password for the key being stored in plain text anywhere else in the software, which will only cause problems for system administrator but not for an invasor. Some time back I saw a software developer required to hash a generated key, store that hash in a text file and use that hash string as the key to encrypt/decrypt the file containing the credentials, the architect was unhappy until the actual key was a string that looked like a hashed password. Can you believe that?
You cannot rely on keyring/keychains for daemons, cause daemons should not be authentication on behalf of users, if they are impersonating users they should be agents and should use a keyring/keychain available on each OS environment.
想要窃取密码的人知道如何root操作系统。不要不要依赖文件权限。这就像在说“请不要阅读此文件。好吗？”
你需要加密那些东西。 Android 有一个密钥环（搜索 api），您可以使用它，但它确实需要密码。请勿在代码中对密码进行硬编码，请向用户询问密码。
当您处理用户的密码时，您有责任。如果你逃避这个责任，他们有一天会私刑处死你。
编辑：哇哦，抱歉，我完全以为这是一个 Android 问题。但仍然使用密钥环和强大的加密货币。
The kind of people who are looking to steal passwords know how to root the OS. Do NOT rely on file permissions. That's like saying "please don't read this file. pretty please?"
You need to encrypt that stuff. Android has a keyring (search the api), you can use that, but it does require a password. Do NOT hardcode the password in your code, ask the user for one.
When you are dealing with your user's passwords, you have a responsibility. If you avoid that responsibility, they will lynch you someday.
edit: woah, sorry, i totally thought this was an android question. But still, use a keyring and strong crypto.
您可以查看 ManageEngine 密码管理器 Pro 中提供的应用程序到应用程序密码管理功能。
基础设施中使用密码与其他应用程序通信的应用程序和脚本可以安全地查询Password Manager Pro，以便在需要时检索密码。
为此，Password Manager Pro (PMP) 提供了两种类型的 API：
这两种形式都使用 PKI 身份验证来允许访问通过 API 进行 PMP 应用。 XML-RPC API 还附带 Java Wrapper API，以便轻松地将其与 Java 应用程序集成。
您可以使用此功能来实现您的要求。
欲了解更多信息：
http://www.manageengine .com/products/passwordmanagerpro/help/application-to-application-password-management.html
You may take a look at the Application-to-Application Password Management feature available in ManageEngine Password Manager Pro.
The applications and scripts in your infrastructure that communicate with other applications using a password, can securely query Password Manager Pro to retrieve the password whenever they need.
Password Manager Pro (PMP) provides two flavors of API for this purpose:
Both the forms use PKI authentication for allowing access to the PMP application through the API. The XML-RPC API also comes with a Java Wrapper API to make it easy for integrating it with Java applications.
You may achieve your requirement using this feature.
For more info:
http://www.manageengine.com/products/passwordmanagerpro/help/application-to-application-password-management.html
谷歌一下权限身份管理产品。一些示例是 Cyber-Ark 的套件：
http://www.cyber-ark.com/
或密码Manager Pro：
http://www.manageengine.com/products/passwordmanagerpro/download.html< /a>
这些工具的优点是，如果服务器被破解，攻击者就需要弄清楚如何从密码存储中检索密码（或从内存中获取密码）。这将更加耗时，并希望让您有更好的机会检测到他们的入侵。还应该可以在交叉检查中识别出这是对密码存储的欺诈请求，因为它没有链接到交易。
另一种选择是在磁盘上对其进行加密，并让用户必须输入 GPG 密钥的密码来解锁密码。如果您能找到一个可以读/写其数据库的良好 API，pwman、passwordsafe 和其他工具可能会支持类似的功能。
Have a google around for Privilege Identity Management products. Some examples are Cyber-Ark's suite:
http://www.cyber-ark.com/
Or Password Manager Pro:
http://www.manageengine.com/products/passwordmanagerpro/download.html
The advantage these tools have is that if the server is cracked the attacker then needs to work out how to retrieve the password from the password store (or grab it out of memory). This will be more time-consuming and hopefully give you a better chance to detect their intrusion. It should also be possible to identify it is a fraudulent request to the password store in cross-checking since it isn't linked to a transaction.
Another option would be to encrypt it on the disk and have the user have to enter a pass-phrase for a GPG key that unlocks the passwords. pwman, passwordsafe and other tools may support something like this if you can find a good API that can read/write their databases.
您是否考虑过创建一个长时间运行的进程来读取密钥（使用密钥环），然后在 UNIX 域套接字上休眠，等待“该做您的事情了”信号？您的 cron 作业可以通过写入 UNIX 域套接字来简单地唤醒这个长时间运行的进程，而无需实际执行该工作。 （因此您的密钥始终保留在内存中）。此外，您始终可以使其 fork() 一个子进程，并将其特权升级为子进程中的 root 权限，以执行需要 root 访问权限的各个活动（而不是始终处于升级状态），而不是给予长时间运行的进程 root 访问权限。如果将其设为“setuid”进程（chown root:root、chmod u+s），那么即使由普通用户执行，它也可以根据需要升级到 root 级别访问权限。
Have you considered creating a long-running process that reads the keys (using the keyring), and then sleeps on a UNIX domain socket, waiting for a 'time to do your stuff' signal? Your cron job can simply wake this long-running process, by writing to the UNIX domain socket, without actually doing the work. (Thus your keys stay in memory the entire time). Moreover, rather than giving the long-running process root access, you could always make it fork() a subrocess and escalate its privilege to root in the subprocess to perform individual activities that require root access (without always being in that escalated state). If you make it a 'setuid' process (chown root:root, chmod u+s), then it can escalate to root level access as needed, even if executed by an ordinary user.