Re: Shared System Certificates followup: Packaging Guidelines?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 14, 2014 at 2:36 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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@xxxxxxxxxx> 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
>>> following:
>>>
>>> 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[1].  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
difference.
    Mirek

[1] http://article.gmane.org/gmane.comp.encryption.general/16128 , my fault.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux