My suspicion is that in the run-up to the major changes Apple has made to Gatekeeper, they painstakingly accumulated a list of 36215 “trusted” hashes and deposited them on everybody’s Mac so that the effect of 10.9.5’s stricter code signing checks would be mitigated. OK, I run a lot of software, but I’m quite positive I have not run 36K unique parcels of code in recent memory. Using some more sqlite3 magic, we can determine the number of unique values in the “current” column: sqlite> select count(distinct current) from whitelist But it seems to me that it must somehow be a way of informing the security system that certain specific (possibly modified?) instances of an app are still essentially the same as the “current” CDHash being tested. I don’t really get what the “opaque” column is about, and my ability to scrutinize Security source code isn’t great enough to easily be able to tell by reading the source, either. For example, a version of MarsEdit that shipped with a V1 code signature and which does not seem affected by the changes in Apple’s Gatekeeper policy has a CDHash of “D1FBA2AB9A4814877BE8C1D2A8615FB48D8D4026”, and on my system anyway there are two rows corresponding to that CDHash. X'CBE56B9784974E0A1C0159C41F392B77421B4D23'īy scrutinizing the code and poking around, I’ve determined that the “current” column is not unique, and corresponds to the “CDHash” of a given code object being analyzed. So what does a typical row from the table look like? sqlite> select quote(current), quote(opaque) \ And there are a LOT of rows in the table: sqlite> select COUNT(*) from whitelist With it, for example I was able to discover that there’s a table called “whitelist” within it, and that it contains two columns: “current” and “opaque”. It’s big! It will be a bit easier to play with if you have any experience at all using the sqlite3 command line tool. var/db/gkopaque.bundle/Contents/Resources/gkopaque.db The whitelist database is stored on your Mac in the following location: on 10.9.5, even though Apple stated that V2 code signatures would be required? Could this explain the fact that many, many people observed that their apps with old, V1 signatures continue to pass Gatekeeper’s scrutiny e.g. In the policyengine.cpp source file, search for “consult the whitelist” and you’ll find the clump of code that very deliberately avoids rejecting an app for its “obsolete resource envelope” if it passes some whitelist check: Poking around today I found something very curious. I can’t believe I didn’t think until now to check Apple’s open source Security framework for clues about this. I wrote previously about the confusion that arose when many developers, trying to comply with Apple’s new code signing rules, ran across strange system behavior in which version 1 signatures seemed to work, yielding the curious system policy message “accepted CDHash.”
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |