Yosemite DP1 adds AppleMobileFileIntegrity.kext to OS X

Crap. This might be bad news. AppleMobileFileIntegrity.kext aka AMFI a sworn enemy of Jailbreakers on this planet… is now also part of OS X 10.10 Yosemite. I have no idea what Apple is up to, but it might mean trouble is ahead of us. More trouble that is.

Edit: I also found /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.apple.MobileFileIntegrity</string>
        <key>MachServices</key>
        <dict>
                <key>com.apple.MobileFileIntegrity</key>
                <dict>
                    <key>HostSpecialPort</key>
                    <integer>18</integer>
                </dict>
        </dict>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/libexec/amfid</string>
        </array>
        <key>POSIXSpawnType</key>
        <string>Interactive</string>
</dict>
</plist>

The daemon is there already: /usr/libexec/amfid but it may require some sort of argument, which may be added in a future developer preview/release.

Update

I checked: /var/log/system.log in Yosemite Update 1 and found an interesting piece of text:

calling mpo_policy_init for AMFI
Security policy loaded: Apple Mobile File Integrity (AMFI)

Seems like the new security scrutiny went life in DP2. Time to debug this…

Ok. Code signing debug data can be enabled by setting a boot argument called cs_debug=[value] where value can be 0x1 up to 0xb.

With 0x1 I got two lines. One for each instance (file/process):

AMFI: <key><com.apple.security.get-task-allow> not found
AMFI: <key><com.apple.rootless.installer> not found

With 0xb you get a lot more data. Here are a few examples:

AMFI: in mmap but not enforcing library validation
[deny-mmap] mapped file has no team identifier and is not a platform binary
[deny-mmap] mapped process has no team identifier and is not a platform binary
AMFI: failed to get file path
[deny-mmap] mapped process is a platform binary, but mapped file is not
[deny-mmap] mapped file does not have a matching team identifier
[deny-mmap] mapped process has team identifier %s
[deny-mmap] mapped file has team identifier %s

Another interesting boot argument is amfi=[value] where value can be used to disable certain parts, like 0x2, 0x4 and 0x80 – or a combination of the values.

kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg
kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg
kern_return_t _initializeAppleMobileFileIntegrity(): library validation will not mark external binaries as platform

I may be wrong, but it looks like there are two more new boot arguments: amfi_allow_any_signature and amfi_get_out_of_my_way
Let me verify this after a cup of coffee…

Yes. Setting amfi_get_out_of_my_way=0x1 also gives me the:

kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg

Adding cs_enforcement_disable=0x1 to the boot arguments gave me one more line:

kern_return_t _initializeAppleMobileFileIntegrity(): cs_enforcement disabled by boot-arg

And there are two more boot arguments that you may want to give a go: cs__enforcement_panic and panic_on_cs_killed

Now I really want my Latte Macchiato 😉