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.

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?

For the Mac OS X technology, 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/s... (may not even compile; not all Apple's open source releases do)

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.

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.