Shared System Certificates followup: Packaging Guidelines?
mitr at volny.cz
Tue Jan 14 18:36:11 UTC 2014
On Tue, Jan 14, 2014 at 2:36 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 01/13/2014 12:50 PM, Miloslav Trmač wrote:
>> On Wed, Jan 8, 2014 at 6:32 PM, Stephen Gallagher
>> <sgallagh at redhat.com> wrote:
>>> Probably this needs to go to FESCo/FPC, but what about
>>> package-specific CAs? For example, I have a pattern I was
>>> thinking about adding to the tog-pegasus that causes it to do the
>>> 1. Create an x509v3 certificate and key with the CA extension 2.
>>> Create a new service certificate for tog-pegasus locally 3. Sign
>>> it with the CA certificate. 4. Store the public CA certificate in
>>> the system's trust store. 5. Destroy the private key so that it
>>> cannot be used to sign other certificates.
>>> (The effect here being that a user on the local system can
>>> connect to an SSL socket on localhost without being challenged or
>>> having to ignore the verification)
>> In general, I probably wouldn't want the FPC guidelines to be
>> specifically describing such a complicated scenario, they would
>> have to be insanely long.
>> Personal opinion on the above scheme: 0. AFAICS it's generally
>> secure and I can't find a strong reason to prohibit it. That
>> said: 1. It is unverifiable that the private key has been
>> destroyed; an attacker could regenerate a CA and the tog-pegasus
>> key, and then continue the use the CA private key to sign MITM
>> certificates, and there would be nothing "out of the ordinary" in
>> the systems' CA configuration.
> How exactly would they regenerate the key? Even if we assume that the
> key is not destroyed, it was still only ever readable by root, which
> implies that the attacker already has sufficient privilege to do
> whatever he wants, including dropping a new trusted CA into the system.
Yes, this story was assuming root access by the attacker. The only
interesting aspect is that it this attack is undetectable: if you take
a pristine image of a VM and a subverted image, you can't tell the
 http://article.gmane.org/gmane.comp.encryption.general/16128 , my fault.
More information about the devel