lldb ...

Rainer Müller raimue at macports.org
Fri Sep 9 03:00:19 PDT 2016


On 2016-09-09 03:38, Jeremy Sequoia wrote:
> You are describing a system to automatically create and automatically
> trust a code signing certificate that contains a private key in a file
> on disk that is not encrypted with a passphrase and only depends on file
> system ACLs to protect it.
> 
> That is trivially insecure and attack-prone.

Adding trust for an additional certificate also only relies on the
filesystem permissions. If I get root write access to System.keychain, I
can add my own certificate.

If we add a trusted certificate to System.keychain and the corresponding
private key is only accessible by root, that would still be the same
level of security in my opinion.

>> Consider that any software can already use your developer certificate
>> from your user keychain to sign whatever it wants. 
> 
> No, it cannot.  It requires my explicit authorization to do so.  I must
> unlock the keychain for it to gain access.
> 
>> You will not even be
>> asked when that happens.
> 
> You should be if you set it up to do so.  If you put your private keys
> in your login keychain, then the act of logging in with your password is
> what unlocks them.  I don't consider that secure enough for my needs, so
> I place mine in another keychain which requires me to explicitly unlock
> it before use.

Fair enough. However, I guess most users only have a login.keychain.

>> I propose we add an additional keychain, readable by root only that is
>> used to sign MacPorts binaries. As root is required to access it, your
>> security would be defeated anyway if anyone gets to it.
> 
> It's great that only root can read it, but it should not be created
> automatically, added to any trusted store automatically, or stored
> unencrypted automatically.  We should instead give good instructions for
> setting it up with either a self-signed or ADC-Provided code signing
> certificate.

Requiring manual setup defeats my goal of just making it work by
installing the port. The status quo is already that everything needs to
be done manually.

> The user should just specify the path in macports.conf.  If it is
> locked, we should prompt for the passphrase to unlock it before use.

Would need both the path to the .keychain and the CN of the certificate,
right?

As a compromise, I would propose we generate an identity in a separate
keychain and sign the binary with it. However, adding the certificate to
the trust store in System.keychain needs to be done manually by the
user. Would you be comfortable with that?

Rainer


More information about the macports-dev mailing list