lldb ...

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 8, 2016, at 17:30, Rainer Müller <raimue at macports.org> wrote:
> 
> On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>>> On Sep 5, 2016, at 03:49, Rainer Müller <raimue at macports.org> wrote:
>>> My intention here is to describe a way how the code-signing can be
>>> automated. We do not gain much by providing a solution that still
>>> requires manual interaction by the user. Generating a certificate and
>>> signing the binary should be completely transparent to the user.
>> 
>> That obfuscation is very bad for security purposes.  We should not hide this detail from users.  It needs to be very explicit.
> 
> At the moment it is very explicit. We have no automation at all and you
> need to do all of the code-signing yourself or gdb/lldb will not work as
> intended.
> 
> The alternative way, recommended in the notes of the gdb port, requires
> disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I
> would consider even worse for security. See [1].
> 
> Where do you see a security risk in adding a new trusted cert?

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.

> 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.

> 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.

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.


> 
> Rainer
> 
> [1] https://trac.macports.org/ticket/49815
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160908/854795a6/attachment.html>