5 ms·

Fundamentally, any secrets you store will have some mode of access - there's a downside to each and every way of distributing them. If you're shelling out to c

Fundamentally, any secrets you store will have some mode of access - there's a downside to each and every way of distributing them. If you're shelling out to commands you think might snarf credentials, the environment is easy for them to pick it out of, but if they're running as the same user then they could probably read the secrets from the config file. If they aren't running as the same user, you need a way of passing in the secrets - and we tend to come back to environment variables.. The good practice here is just to reset the environment when calling shell commands, as he notes. It's not hard to do.

mreinsch 12y ago
You're right that a tool which runs under the same user could read your config file and thus could access to your secrets. But there is one main difference: that tool would need to do so explicitly, with the intent of reading (and possibly exposing) your secrets. For me, that's a huge difference from having the secrets being implicitly available to the process through the processes environment.
- ealexhudson 12y ago
  It doesn't need to do so explicitly: it just needs to have a bug that can encourage it to do so. Most environment leakage also needs to be triggered too.
Someone 12y ago
You could use a kernel service that checksums the calling DLL or even all code loaded in the calling process and compares that against a list of trusted callers before doling out the secret. Disadvantage, of course, is that you will have to update the list of trusted callers whenever they change. Mac OS X automates that by automatically trusting binaries signed with the same key (trades some security for convenience) Another disadvantage is that this doesn't work well with scripts (the kernel service would have to know how to find the running scripts in order to checksum them, for every possible scripting language on the system). Also, any form of extension support in a trusted application is problematic.
- alexatkeplar 12y ago
  Wow, this is the only thing I've seen in this thread which doesn't just add another layer of turtles to the problem. With your suggestion, even if an attacker could gain access to the box, they wouldn't be able to get at the secrets. Is there any prior art/blog posts/software for this approach you could point me at?
  - Someone 12y ago
    For the Mac OS X technology, https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html https://developer.apple.com/library/mac/documentation/Securi... is a good starting point. I don't know of full open source equivalents. Parts of Apple's code are open source, though, for example http://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-55202/src/ http://opensource.apple.com/source/security_systemkeychain/s... (may not even compile; not all Apple's open source releases do)

mreinsch 12y ago

You're right that a tool which runs under the same user could read your config file and thus could access to your secrets. But there is one main difference: that tool would need to do so explicitly, with the intent of reading (and possibly exposing) your secrets. For me, that's a huge difference from having the secrets being implicitly available to the process through the processes environment.

ealexhudson 12y ago
It doesn't need to do so explicitly: it just needs to have a bug that can encourage it to do so. Most environment leakage also needs to be triggered too.

Someone 12y ago

You could use a kernel service that checksums the calling DLL or even all code loaded in the calling process and compares that against a list of trusted callers before doling out the secret. Disadvantage, of course, is that you will have to update the list of trusted callers whenever they change. Mac OS X automates that by automatically trusting binaries signed with the same key (trades some security for convenience) Another disadvantage is that this doesn't work well with scripts (the kernel service would have to know how to find the running scripts in order to checksum them, for every possible scripting language on the system). Also, any form of extension support in a trusted application is problematic.

alexatkeplar 12y ago
Wow, this is the only thing I've seen in this thread which doesn't just add another layer of turtles to the problem. With your suggestion, even if an attacker could gain access to the box, they wouldn't be able to get at the secrets. Is there any prior art/blog posts/software for this approach you could point me at?
- Someone 12y ago
  For the Mac OS X technology, https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html https://developer.apple.com/library/mac/documentation/Securi... is a good starting point. I don't know of full open source equivalents. Parts of Apple's code are open source, though, for example http://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-55202/src/ http://opensource.apple.com/source/security_systemkeychain/s... (may not even compile; not all Apple's open source releases do)