unsigned kexts on Yosemite

[Landon J Fuller]

On Oct 22, 2014, at 5:25 PM, Ryan Schmidt <ryandesign at macports.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20141023/a9e7d2ce/attachment.sig>