lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 8, 2016, at 15:13, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>>> codesign.files       ${prefix}/bin/binary1 developer \
>>>                    ${prefix}/bin/binary2 firewall
>>> codesign.identifier  org.macports.${name}
>> 
>> 
>> I don't like this approach.
>> 
>> We should solve this type of problem at the base layer.  Everything should be codesigned as configured in macports.conf (using a specified identity in a specified keychain, or defaulting to adhoc).
> 
> I think you'll also need to specify the user who owns the keychain, let's call him/her the macports_operator.

That's not really necessary.  All that is relevant is that the macports user has read access to the file.

> Technically it doesn't really matter if it's implemented in "base" or in a PortGroup, right?

In order for *every* port to benefit, it needs to be in base.

> I like the idea of a PortGroup because it allows to deploy the new feature without waiting for a new base release, and also makes pushing updates so much easier.

If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign everything" case.

> Similarly, it shouldn't really make a difference whether the information is read from macports.conf or somewhere else - but I suppose a PortGroup can read from that file too.
> 
>> The port itself should build() using adhoc signing, and base's post-build should resign everything (preserving all attributes) using the settings specified in macports.conf.
> 
> build{} and post-build{} are executed as ${macports_user}, right? That should be compatible with my observation that codesign will change ownership of the target file (unless it's executed as root).

Ah, right, sorry.  Mixing up build system paradigms.

build{} would sign it adhoc.
post_destroot{} would resign it as specified in the macports.conf

> There are 2 details to work out:
> - HOME is set to ${prefix}/var/macports/home (~macports)

HOME is irrelevant.

> , not to ~${macports_user} i.e. not the home directory of the user specified via the macports_user variable. It will need to point to the home directory of the user who owns the keychain (${macports_operator})

No, it doesn't.

> - evidently ${macports_user} will need to be able to read the required keychain, possibly every directory in the path to that keychain.

No, the user doing the signing in post_destroot{} would be root.

> The first detail is trivial, the 2nd a bit less. I get around it because the post-activate{} step executes as root, so read access is automatic. The only easy way to solve it for the macports_user is to let the keychain be owned by that user.

If you want the macports user to do the signing, that's fine too.  It doesn't need to own the keychain, just have read access to it.  It could be group read access or other read access.

> I've tried to set things up that way by preparing a keychain with a signing certificate and its 2 keys. Once that's done you can automate the process of installing that keychain in ~macports/Library/Keychains and adding it to the search list via the security command. However, codesign refused to find that identity, when called by macports user. There's a transcript of my attempts in an earlier of my messages in this thread.
> The base layer could of course do a dedicated post-build that is executed as root. I presume...

Yes.

>> This approach allows us to specify an identity on the builders that is an apple developer signing identity such that all binaries coming out of MacPorts have a chain of trust back to Apple.
> 
> Is that something we want

I'd say most definitely.

> (except for things like kexts in ports like the one I once proposed for ZFS) and is that something that Apple would accept

I don't see why not.  I have such a key for XQuartz.

> ... without requiring a vote in when updates can be published, what can be accepted etc?
> I also don't really see why it would be bad to allow ports to let users sign or resign binaries with an identity of their own.

That should be controlled at the base layer.  We shouldn't have a mixmatch of signing identities for different files as that will break library validation for any ports that might need LV.

> If you allow that for building from source, why not allow it for prebuilt packages too? Can you give an example what's so incredibly dangerous about resigning code that was signed on the buildbots?

You could certainly resign it after first validating the original signature.

Signing unsigned code without first validating it is a clear security concern.

> I can see that for things like kexts (which will be rejected anyway if you resign them with an inappropriate key), but for most other stuff in MacPorts? I know of only 1 port that actually requires signing the binary after installing - gdb. All the others I can think of are apps like kmail and family (port:kdepim) which *benefit* from signing to stop the nagging about "do you want this application to accept internet connections". And that can be handled just fine with the ad-hoc identify.

If that's the case, then my proposal seems perfect.  It results in everything being adhoc signed by default and lets power users (and the buildbots) configure their system to resign executables with a configurable key.

>> That obfuscation is very bad for security purposes.  We should not hide this detail from users.  It needs to be very explicit.
> 
> A middle ground can probably be found, one that makes it easier for users (and/= increases the likelihood that every user gets it right the 1st time) but that still requires some form of explicit action from the user.
> 
> If you look at lldb's instructions for setting up a signing key it isn't very explicit at all what's going on for someone who (honestly?) doesn't really care. It's just tedious. I think that a good compromise would be if an implementation of a codesigning procedure prints the command to execute (a script provided by macports) as a function of the signing requirements, a command that the user can then paste in a CLI . Probably a set of commands; one to create and populate a keychain in the own keychain directory, and a sudo'ed one to install that keychain where it should go, if needed.

If the user can't be bothered to create a codesigning keychain and edit macports.conf, they probably aren't going to be trying to setup their own custom lldb installation in the first place and are probably content with the one provided by Xcode.

>> The user should create a keychain and specify the path to the keychain in
>> macports.conf.  If that's not set, we should just adhoc sign.
> 
> What I don't like about ad-hoc signing is that there is just about no information what that does.

What do you mean by that?  Can you elaborate?  I don't quite understand your question.

If you use '-' as the identity, an adhoc code signature will be used.  This stores the code hash and other metadata, but it is not signed with a key/cert.

If a mapped page does not meet the image's signature, it'll either not be loaded (if CS_HARD), the process will be killed (if CS_KILL), or the process will just become !CS_VALID, just like with a real code signature.  The extra bit that a real code signature adds is that the signature is validated against the signing certificate before it is trusted, and the process becomes !CS_VALID if the cert itself is untrusted or the signature does not validate.

If an image has no code signature, then it is treated differently on iOS compared to macOS; on iOS, such tainting causes the process to become !CS_VALID (and likely killed by CS_KILL), but on macOS, lack of code signature does not change the CS_VALID state of the process.


>> It should be unlocked by the user providing the password to unlock the
>> keychain.
> 
> Is that going to work if codesign is executed as macports, or a UID that's not root and doesn't belong to the user currently logged in?

Yes, it just needs read access to the file.  That's just gated by filesystem permissions.

> 
> R. 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160908/dea79e51/attachment.p7s>