> On Sep 8, 2016, at 15:13, René J.V. Bertin <rjvber...@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@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
