Unsigned kexts cannot be used on 10.10 #31164
Comments
|
Or, longer-term, perhaps we sign the kexts we provide in our bottles. Regardless the future of such things is distributing binaries (which I think is a good thing, actually). |
|
That could work too, although would that add onto the costs of running Homebrew in terms of having to obtain an OS X development certificate? I don't know what the current costs to donations ratio is, nor what financial burden those doing the maintaining take on, so I'll leave any comments on that side of things to those in the know. The second part of your reply took me off-guard slightly. I'd always presumed Homebrew was partly brought into existence by the pro built-it-from-source attitude, and later became this fantastic hub of easily porting across software that provides no binary for the platform in question. I confess despite having hunted around the web a bit for a decent history of Homebrew I haven't really come across anything in-depth, so I may be guilty of viewing Homebrew through the rose-tinted glasses of my own love of source-code building. |
|
Yeh, we might need to buy a certificate. We've got a bit of money stashed away though if we decide this is worthwhile. I wrote the binary package/bottle support so I'm biased but I see build-from-source as being something that's useful for developers and maintainers to produce binary packages that are consumed by end-users. Even with the sandboxing we do the potential for things to go wrong are vastly higher with source packages, unfortunately. |
|
Alright. Let me know if that becomes more urgent and I'll happily cough up a little cash to aid with that. Somewhat frustratingly there is nothing in the pre-release 10.10 documentation explaining their move to kill all unsigned kexts. The change happened in DP4/PB1, but the only reference to it so far is (Unrelated note, 10.10 gets a Python version bump to I certainly have no quibbles about source packages having the ability to go vastly more wrong than binary releases, that's something I see pretty often. I'm still a little rough around the edges in understanding the full Homebrew bottle system, but I understand the underlying process & intent behind it. Part of my enjoyment in source packages is being able to set the initial configuration and then to have a very hands-on grasp of where things are going wrong, when/if they do. I often feel with binaries that I don't get that same level of understanding on all of the mechanisms in play, but because of that, perhaps I'm not the 'average consumer' in tech. I guess most people just want things to work. I kind of actively enjoy things not working and then figuring out how to make them work. |
|
I bumped into this problem last Saturday. I tried to contact the author of tuntaposx, but got no reply. I found a signed tun/tap.ext in a beta bundle of tunnelblick. After I put signed externsions in /Library/Extensions and changed their permissions, tuntap worked as expected. The problem is solved for this case. For those who have upgraded to Yosemite and do not want to downgrade, and who need to use openvpn and stuff like that, this is a temp workaround. However, I do think we need to find a better way to distribute some developer signed binaries. I'm not familiar with the signing process, but I guess the certificate should not be included in the source code, is that right? If that's the case, I propose we add a sub command similar to cask, and install pre-built and signed binaries for end users, so they could do something like: |
|
It's worth noting that right now, if you need to run unsigned kexts you can disable the signing check mechanism. It will be disabled for all kexts, which isn't the most comfortable or pleasant solution in the world, but we'll see where Apple takes this decision over the next few DPs, given the unsigned kext ban was only implemented in DP4. You can turn off the kext checks by doing censored and rebooting. Be aware this will disable all kext signing checks. |
jacknagel
changed the title
|
Do they need to be signed by an Apple-provided certificate? Is there a way for an individual user to trust a self-signed certificate of their choosing? Or is there a way for an individual user to get a free certificate from Apple? |
|
A) Right now, yes, they either need to be signed by Apple or signed by a valid Apple OS X Developers Certificate. B) This isn't entirely clear just yet. Apple has issued no documentation on the kext signing changes from DP4, other than a note in the release notes highlighting that unsigned kexts would no longer load. Right now you even have to justify each kext signing to Apple, before they'll allow that kext to be recognised as signed. You can sign kexts with an OS X developers certificate but unless Apple sticks that kext on their approved list it won't work on anyone but the developer's Mac. One would hope if they're going to tighten up the kext rules this much that process may become easier, but it's an unknown for now.
|
|
The author of tuntaposx replied my mail. He said he would obtain a certificate and provide a signed version of tuntaposx soon, though it would need sometime. The question remains as to what could be done to the other kexts. |
|
Interestingly, AppleKextExcludeList.kext still exists and its info.plist contains a new dictionary called and thus: It's preloaded with a lot though, including: <key>08a337bec50185b6afedbe6ad1e4abb1dfc70fbb</key>
<string>org.fuse4x.kext.fuse4x 0.9.2</string>
<key>4549c475ca3e138881124d13ce608c285cecc95a</key>
<string>com.github.osxfuse.filesystems.osxfusefs 2.6.4</string>
<key>008f7d23b07b898a0b1e06645d696bbb50fe8ac5</key>
<string>net.tunnelblick.tun 1.0</string>
<key>01ada26d5f2ea4318a0c1c3d0210f9066c4f1210</key>
<string>foo.tun 1.0</string>
<key>0507422ef41327ba4927a857f27444e6c2055270</key>
<string>net.tunnelblick.tap 1.0</string>
<key>05a6c717cbf50e17f6240d3a18fb3fdb70a21001</key>
<string>com.pandapow.tun 1.0</string>
<key>315ac89356ec7c6f6c204e93aeffb81e8c5a56db</key>
<string>com.chungwasoft.Shimo.tun 1.1</string>
<key>3cae18378274ad5ef283313c2b85922d1d3808df</key>
<string>com.anchorfree.tun 1.0</string>
<key>4086f44dd3fe966ff981205fb2b349cdd3fa055e</key>
<string>net.tunnelblick.tap 1.0</string>
<key>422ed4a139aea4f1a96012c4a878c2159416dd71</key>
<string>me.faceless.tun 1.0</string>
<key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
<string>com.frozenway.tun 1.0</string>
<key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
<string>com.frozenway.tun 1.0</string>
<key>e5d27ef0b936725dd59a1d0c98f888940fb6405b</key>
<string>com.joshuawise.kexts.HoRNDIS 1.0.0d1</string>It also has different versions for most of those, and even many listings of the same versions with different hashes. I couldn't find any for gpsim though. Surprisingly, I did find a number of kexts that are used for Hackintoshes: <key>072e4303f63f6a6ca1c95586d1ff5f7ee5b11ab6</key>
<string>org.netkas.FakeSMC 4.2.0</string>
<key>776abf8cb3f21fdbc8b08e8854364e189e832260</key>
<string>com.insanelymac.RealtekRTL8111 1.1.2</string>
<key>e70e8203cc7536175c4bf796af980904afc62ce1</key>
<string>com.tonymacx86.AHCI_3rdParty_SATA 1.0.0</string>
<key>fa7afd75eeab54101a2fef9b1fc14394d17d7c04</key>
<string>com.tonymacx86.JMicron36xSATA 0.8</string>
<key>2a9eeb0770dae64732bc99cba196e04abbcb9bd9</key>
<string>com.tonymacx86.ALC8xxHDA 3.0.1</string>
<key>5710e33e6279136ffd00e8cc19d808ed45dd24a9</key>
<string>com.Niresh12495.Hackintosh.AHCIPortInjector 1.0.0</string>
<key>b90204a1b180844790019e0976b77cbf792f818e</key>
<string>com.Niresh12495.Hackintosh.ATAPortInjector 1.0.0</string>
<key>e8040befa56ae5b258dce573609b24ad93216344</key>
<string>com.Niresh12495.Hackintosh.IOAHCIBlockStorageInjector 1.1.1</string>So can this be taken as a tacit endorsment of Hackintoshes? Anyways, in my opinion, this is a rather troubling move. Users should be able to install kernel extensions without a certificate without having to disable an important security measure for other kexts. Hopefully this isn't indicative of a continuing trend. My nightmare scenario is mandatory Gatekeeper for all executables, thus requiring people to jailbreak their Macs if they want to be free. |
|
As for the current contents of the kext exception list, this is identical to the early Mavericks beta list. The early Mavericks beta kext exception list included every popular kext Apple knew to exist, and the list was whittled down over subsequent releases. They appear to be taking the same tact to Yosemite's list, with early exceptions for everything and then slimming the list down as devs have time to validly sign their kexts. The Hackintosh kexts were there in the early Mavericks betas too, and then vanished, so I suspect that will happen this time as well. Don't expect Apple to ever get on board with Hackintoshes for the same reason they don't approve of jailbreaking, in that they see both as having a negative impact on system security & stability. |
|
Indeed. I figured that's why it was complaining about an invalid signature in the log. Interesting, I didn't know that was in the Mavericks betas. I don't actually expect them to endorse jailbreaking or Hackintoshes any time soon (if ever), which makes it all the more surprising that they are explicitly accommodating kexts that are only used on non-Apple hardware. I was especially surprised to see FakeSMC (a kext that masquerades as a real Mac's System Management Controller) on there. Was kext signing also enforced like this on the Mavericks betas? Or was modifying the kext exclusion list allowed like it is in the 10.9.x releases? I just noticed that the wording in the release notes doesn't explicitly state that this will be a permanent policy.
Do you suppose there's any chance that they will drop this restriction in the release version? Or should it just be assumed that they intend to keep new introductions to the developer previews? Perhaps they just want the kernel environment to to be clean in the previews for consistent testing and feedback. |
|
Mavericks introduced the idea of requiring kexts to be signed, but it never enforced it. You'd get a nice big Console warning if you ran unsigned kexts, but that'd be it, they'd still run. From Yosemite they've killed all unsigned kexts from running at all, unless you disable that security measure entirely. AFAIK, You couldn't modify the kext exclusion list in the Mavericks betas either, although there wasn't especially a requirement to given that 10.9 never actually enforced the kext signing issue. Somewhat frustratingly, from DP5 they've tightened up the overall code-signing rules even more, which isn't going to be a big issue for anything built locally from source but still, makes lives of devs a wee bit more troublesome. As of DP5 you still need to sign your kexts for them to run. I'm probably going to open up an issue upstream about this to see if Apple is willing to write in rules that permit end users to allow specific unsigned kexts run rights, but I wouldn't be surprised if I get a 'Nope' on that. If Apple wasn't expecting or intending to keep the unsigned kexts rule into the release versions I would have expected them to include it in the earlier DP releases. That they waited till DP4 to include it says to me they consider this idea ready for wider implementation. I'm going to ask upstream though, and see if I can get some clarity on the kext issue. Theoretically, any reply I get is covered under the NDA, but if I can share some more information without breaching that I'll do my best. |
|
FWIW, this is no different from the driver signing requirements on Windows 7+. No unsigned drivers are allowed to run unless you disable signature verification system-wide. |
|
Most things ship with compiled binaries for Windows though. It is the prevalent OS. Due to OS X's UNIX heritage, quite a few popular utilities ship as source packages rather than compiled binaries (Especially true of things that were created for Linux & then ported across to OS X). I think it'll have a more noticeable impact here than it did on Windows, for better or worse. |
|
Is it possible for us to sign kexts for bottles? |
|
Theoretically, It's difficult, because Apple still mandates each kext certificate must be first approved by Apple. Theoretically, you can't just use one certificate to sign each kext, you must have a new one for each kext. Obtaining them is easy enough, but it'd put not insignificant burden on Homebrew to obtain a kext signing certificate from Apple for every kext we ship and then ensure only that kext is signed with only that certificate. In practice? Not really sure yet. Nobody has tested the depth of this policy this early in. It may also be possible for Homebrew to obtain a wide exclusion permission from Apple for the kexts we ship, ie, get every com.mcxl.homebrew.examplekext onto this list which would permit them to run. Apple has been permissive about what goes onto that list so far, so option 2 may actually be easier than option 1. |
|
So basically: not really. I think it's better for these things to be distributed as binaries anyway, personally. |
|
Yeah, I'm not a huge fan of binaries, but when it comes to the new kext permissions we're probably better off and making life easier for folks to ship the upstream signed binaries or merely point people to those instead of trying to kext sign everything in Homebrew. |
To clarify, with a standard, Apple-issued OS X Dev Program Certificate, I can sign a .kext and have it run on my system, but not on someone else's system? And a .kext signed by a self-issued code-signing certificate (generated through Keychain Access > Certificate Assistant) will not work under any circumstances? (If I understand the codesigning documentation correctly, it seems like standard .apps and binaries can be signed with a self-issued certificate so long as the certificate is marked as trusted in Keychain Access. If this policy doesn't extend to .kexts then this is an incredibly frustrating and worrying change.) |
|
Also, all homebrew kext autoloading relying on /Library/StartupItems will not work anymore on Yosemite. Need to rewrite to use /Library/LaunchDaemons. |
|
For those who have a Apple Dev account and want to know more about the changes causing this or how to sign your own kext(need mac dev account) here is the presentation from 2013 WWDC https://developer.apple.com/videos/wwdc/2013/?id=707 |
To number 1, yes, if you are part of the OS X dev program you can still sign your own kexts and they should run. But if you want it to run on someone else's system you'll need to obtain a kext signing certificate specifically for that kext from Apple. This requirement was actually implemented last year, but they decided not to enforce the unsigned kext ban on Mavericks and consequently most people didn't bother to issue signed kexts as the worst that would happen is that the syslog would contain a warning about using an unsigned kext but consequently most users never ever saw that flagged up. To number 2, I haven't actually seen any guidance on that yet, but yes, that is my understanding thus far.
Yes, StartupItems has been depreciated formally now. |
That's an understandable desire, but as you said, an upstream issue. I have actually opened a request upstream asking that Apple permit users to disable kext checks on single specific kexts through the command-line, to permit easier development and debugging, but whether Apple ever act on that or not is entirely down to them.
Osxfuse very quickly issued a signed binary containing a signed kext, and consequently Homebrew switched to supporting both the signed binary and kext for everyone, including Yosemite and the source package for <Yosemite. Where things previously relied on the source package you can now use the upstream binary. |
|
Instead of creating a second issue I'll post this update here since @DomT4 mentioned tuntap by name. About 15 hours ago a new signed version of tuntap got uploaded. Relevant mailing list post http://sourceforge.net/p/tuntaposx/mailman/message/33000809/ Maybe people will want to wait until the author releases the next major version, but as of now I'm up and running with the tuntap_20141104.tar.gz binaries. I did however have to remove all previous versions of tuntap and tunnelblick's kexts with kextunload and removing the kext folders outright (including the scripts in /Library/StartupItems). |
|
See #33894 for movement on tuntap. Those kexts are considered released, but Mattias is waiting for a couple days to see if anyone flags up any issues before pushing them front and centre on the website. I unloaded and reloaded them into the kext bank about 25 times last time and didn't hit any issues at all, nothing in the console, no errors, no problems on reboot, so it looks like Mattias has done a great job here. Having to remove all traces of the unsigned kexts is expected. Hopefully people will do that and then update to the signed binary. We'll be supporting those signed kexts ASAP, and re-enabling functionality of the things that depend on tuntap for Yosemite. |
I have a CA, and code-signing certs. I've been able to successfully sign code and set up policies that would allow code signed by the given certs to be installed and executed. However, that does not seem to apply to kext (kernel extensions). Despite the kext signatures being accepted and validated by codesign and spctl, kextutil insists that the signature is invalid. Here's the output I'm getting: On Mavericks this kext loads with a warning message, on Yosemite it will not. I noticed on Stackoverflow that the cert must have the following extension: How do I add this extension (preferably within Keychain Certificate Assist, though an OpenSSL-based solution would be fine too), short of paying Apple annual "usage fee" of $100? |
I'd suggest you take this to StackOverflow instead. |
|
Just did. :-) Would you like me to delete my post from here? I think this kext thing impacts home-brew, macports, and probably others as well. |
|
I found your post a useful technical insight, so I'd be happy to see it stick around if Mike has no objections. The kext thing indeed impacts MacPorts, Fink, and anything else that ships with unsigned kexts as well. I'm not sure how/if MacPorts and Fink are working around the issue at this point. |
|
@DomT4, thank you! I see only three options:
|
Long term, for security-reasons and Yosemite-enforced-reasons, always shipping signed kexts where available will probably become the default over source packages. Kexts do wield an enormous amount of power, and mandating their signing is a more secure (if irritating) route to go down. |
|
Yes I concur - for security reasons kext should be signed. So I didn't even list the 4th option - allow installation of unsigned extensions. But I really hate seeing computer owners prevented from adding their own extensions to their own kernels... Which is why I really want to find an answer to (3) above. |
|
Yeah. I did put in a request to Apple a couple of months back along the lines of "Instead of either permitting no unsigned kexts or all unsigned kexts could we possibly permit a specific unsigned kext from the command line?" but they haven't got back to me yet on that, and I don't know if they will to be honest. |
|
To the ability to run selected unsigned extensions, I'd prefer the ability to run selected self-signed (or signed with my own cert chain) extensions. Here's the Stackoverflow thread for this issue http://stackoverflow.com/questions/26830800/cant-sign-kext-in-mavericks-yosemite for those who'd like to continue and/or explore it further. |
Enough with this silliness, please. Take it to the mailing list and/or install Linux where you can install whatever you want. |
|
Any word on the progress for getting tuntap to work and how to install the package? |
|
Tuntap have released an upstream binary which is signed and works great. It's available on the Sourceforge download page. Was gonna give you a direct link, but SF is down right now. |
|
Ok thanks. I'll try downloading the binaries once SF is back up. |
|
I punted it to Homebrew/Cask to see if they have any interest in shipping it. Given there's no longer a way for Brew to ship it on Yosemite due to the unsigned issue, It'd be good to have something within the Brew ecosystem able to service users looking for an easier install. |
|
I have no problem, for the moment, with running OS X with the kext security measures it had this time last year, and for the moment that is what I am doing. It's kind of a bummer that there's no way for idiots like me to install kexts from source with homebrew short of modifying formula in-place. |
|
Closing this out as it's pretty much resolved now. |
|
Just to round my last post out, the Cask accepted |
|
My only issue with recommending Cask is that |
|
Yeah, the |
|
Homebrew has some bugs too. I think their project is good and I'd like to see us point to it more. |
|
Yeah, no system is perfect. The Cask is doing a major refactor of their backend at the moment, so Homebrew changes no longer break it unexpectedly, which should allow both Homebrew and the Cask to change backend code more without having to worry about breaking everything for someone else. Some interesting stuff planned going forwards. |
This is going to be a big pain in the behind for Homebrew, MacPorts, and compiling things from source generally.
Currently, from 10.10, the system no longer permits unsigned kexts to run, at all. The only public way to circumvent this 'security' measure at the moment is to disable all kext signing checks, which is a less than delightful solution.
The other way is limited to those with Apple development signing capabilities, which involves signing the kexts with your own certificates which will then enable them to run under Yosemite.
So far, this is already causing issues with tuntap and osxfuse [https://github.com/osxfuse/osxfuse/issues/150]. Right now, actually attempting to build osxfuse from source on 10.10 causes my entire system to panic out. I'm unsure on whether that is related or whether something in the latest DP upset the osxfuse build process.
Not really sure how Homebrew goes about dealing with this problem. Either we advise people to turn off kext signing checks, or we refuse software that utilises kernel extensions. Either solution kinda sucks.
The text was updated successfully, but these errors were encountered: