Hi,
On 2013-09-10 08:30, Jan Ingvoldstad wrote:
> On Tue, Sep 10, 2013 at 2:18 AM, Adam Spragg <adam@???> wrote:
>
> > I'm not happy having an unprotected private key lying about anywhere, even
> > if
> > its permissions were 0400 - let alone 0440 as Exim requires.
> >
>
> Then why are you happy about entering the password in a command line prompt?
>
> In other words, if you don't trust your system's integrity, why do you
> trust your system's integrity?
I trust my system's integrity *now*. But, these things called 0-day exploits
exist. I admit the possiblity that my system might be compromised in the
future. That's why I also run chkrootkit and tiger on a regular basis, among
other integrity checkers.
> For server administration, having to enter the password at every proper
> configuration reload is a huge hassle. It may work on the home server
> scale, but even so, it is a disproportionate hassle compared to the
> illusion of extra security it provides.
Yeah, I guess if you've got a huge server farm where you're updating your
configuration on dozens of machines constantly, then finding the additional
budget for enough admin time to type in your private key passwords as required
is probably a big problem.
Wait, what?
> I think it's important to consider what it is that you're securing, and why.
My system, because it's valuable to me. My keys are valuable; it costs money
to get them signed. If my system is compromised, but I can be reasonably sure
that my private keys are OK, then on top of all the other cleanup I have to
do, I don't have to revoke the old keys, generate new ones, and pay to get the
new ones signed. I can just restore the existing keys from secure offline
backups and go again.
If Exim is compromised, and an attacker can read my public keys off in the
clear straight off the filesystem as the Exim user, my confidence that they're
secret is low. If they need to escalate to root to read them in the clear,
that's better. If they - or any other compromised process with an escalation
to root - needs to search through a program's data structures or a whole 64-
bit address space, in order to find a decrypted copy of the private key,
better still.
And that's not even getting into the possible physical theft of hardware.
http://en.wikipedia.org/wiki/Defense_in_depth_(computing)
> I think what you're asking for is a bad idea,
Keeping private keys as locked down as possible is "a bad idea"? Wow. Maybe
you should submit a patch to the Apache project to remove their implementation
of the misfeature of allowing for encrypted private keys, and all the
unnecessary code required to read passwords from the console. Patches that
remove code and simplify things are normally welcome in most projects, so
they'll probably thank you loads.
> for no practical security
> improvement.
That's certainly up for discussion. You might be right. Maybe, maybe not.
You've not convinced me yet though.
Adam
