On Oct 22, 2014, at 5:25 PM, Ryan Schmidt <[email protected]> wrote:

> 
> On Oct 22, 2014, at 1:40 PM, Dan Ports wrote:
> 
>> I haven't upgraded to Yosemite myself yet, but I'm hearing that in
>> 10.10 the system refuses to load any unsigned kernel modules by
>> default.
> 
> I can understand the security motivations behind this change. You don't want 
> untrusted code running in your kernel.

It’s no more untrusted than any other code being run from MacPorts :-) I think 
users have the right to decide what level of trust they place on a piece of 
software irrespective of whether Apple agrees.

>> Worse, the only option for working around it appears to be
>> turning off signature checks entirely.
>> 
>> This is obviously a problem for ports that build kexts, like osxfuse.
>> What can we do about this?
> 
> We could remove these ports from MacPorts. Are signed binaries of them 
> available from their developers? If not, we could encourage the developers to 
> provide them, and refer them to this issue.

The problem I see here (other than that this breaks the MacPorts model of being 
able to build software directly) is that Apple requires developers to submit a 
special request containing written justification before they can receive a 
signing certificate that may be used for kext signing. Apple may either approve 
or deny the request based on just about any arbitrary criteria —  friends who 
are writing Mac OS X technical books have had their requests denied. On the 
other hand, my request for a signing certificate for a USB hardware driver was 
approved.

Ideally, xnu would support adding a custom CA trust with user approval; we 
could then either generate a per-machine CA that could be used to sign local 
kexts, or a MacPorts CA that was used to sign pre-built binary packages. AFAIK, 
xnu doesn’t support this.

Assuming I’m not wrong about that, I think we should do the following:
        - Try to secure a MacPorts kext signing certificate that may be used to 
sign binary packaged kexts. Securing the kext signing path when building 
packages will require a degree of effort on our part — something I’m very 
willing to help with — but to be honest, I think it’s unlikely that we’ll 
actually get the certificate in the first place.
        - Use nvram(1) to check for kext-dev-mode=1 on Yosemite. If the user 
installs a package containing an unsigned kext, emit the following warnings:
                1) The kext will not be useable without setting kext-dev-mode=1 
via nvram
                2) Setting kext-dev-mode=1 will allow *any* unsigned kext to 
run; this may not be what they want.
        - Use developer-signed binary kexts where available. This is not ideal, 
but it’s reflective of the new reality on Apple’s platforms.

-landonf

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to