csrstat v1.7 released…

I wrote the csrstat command line took back in 2015, after the first beta of El Capitan was seeded, and shared it some time later on my Github repository. Today I’d like to show you the new and improved output of csrstat v1.7 for High Sierra:

csrstat v1.7 Copyright (c) 2015-2017) by Pike R. Alpha
System Integrity Protection status: enabled (0x00000080) (Custom Configuration).

Configuration:
	Apple Internal............: 0 (disabled)
	Kext Signing Restrictions.: 0 (enabled)
	Task for PID Restrictions.: 0 (enabled)
	Filesystem Protections....: 0 (enabled)
	Debugging Restrictions....: 0 (enabled)
	DTrace Restrictions.......: 0 (enabled)
	NVRAM Protections.........: 0 (enabled)
	Device Configuration......: 1 (enabled)
	BaseSystem Verification...: 0 (enabled)
	User Approved Kext Loading: 0 (enabled)

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Three lines more than what you get from: csrutil status

System Integrity Protection status: enabled (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: enabled
	Debugging Restrictions: enabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Not only that. It also reads csr_active_config and tests for 0x8 (CSR_ALLOW_KERNEL_DEBUGGER), 0x11 (CSR_ALLOW_UNTRUSTED_KEXTS/CSR_ALLOW_UNRESTRICTED_FS) and 0x180 (CSR_ALWAYS_ENFORCED_FLAGS), and shows the output based on the used booter (boot.efi or bootbase.efi) and the used settings.

Edit: There is something wrong with the output of v1.5 and I need to look into it. Will try to do that later today. Much later I’m afraid.

Update: The changes to v1.6 were not enough, but v1.7 now shows the correct output here. Please test and confirm that this one works. Thank you.

Advertisements

makeInstallSeedScript.py

Some people still prefer my bash scripts to download the latest seed so I wrote another script. One that I’d like to present to you today. The script is called makeInstallSeedScript.py and it does exactly what all previous bash scripts did before. But from now on. You won’t need to rename and update the scripts anymore; my latest creation will do the job for you.

Special thanks to fellow Googler Brian for his help; ideas, testing and committing the script and template for me. Thank you! I know that you are short on time, but I could not have done it without you!

Q: You know. I’m not much of a Python coder so if anyone here has some tips for me to improve my script, or any other script that I wrote. Please. Much appreciated.

Updates:

Version 1.2 is now available. This update will download the required template file.
Version 1.3 is now available. This update will download the right i18n dictionary.
Version 1.4 is now available. Comment only change.
Version 1.5 is now available. Indentation and comment errors fixed, superfluous code removed. Now gracefully exits, with instructions to install pip/request module.

Price of Intel Xeon W with 14 and 18 Cores…

Intel recently released the Xeon W processor line with the following price tags:

Intel® Xeon® W-2155 $1440
Intel® Xeon® W-2145 $1113
Intel® Xeon® W-2135 $835
Intel® Xeon® W-2133 $617
Intel® Xeon® W-2125 $444
Intel® Xeon® W-2123 $294

But the processors with fourteen and eighteen cores will only be released in Q4 and thus their price is still unknown. But are they? I mean. Come on. Have a look at the Intel processor price list. Take a look at these:

E5-2650 v4 $1445
E5-1660 v4 $1113
E5-1650 v4 $617
E5-2623 v3 $444
E5-1620 v4 $294

Do you see what happened there? Well. In that case you probably come to the same conclusion for these two:

Intel® Xeon® W-2195 $2424 (same as E5-2695 v4)
Intel® Xeon® W-2175 $1846 (same as E5-2683 v4)

Both guesstimates, but one thing is for sure, and that is that they will be bloody expensive. Man. AMD must be partying all day long…

iMac Pro comes with Xeon W Processor…

The wait is over. Intel today formally released the Xeon W processors and here are the three processors that will be used in the iMac Pro:

Intel® Xeon® Processor W-2135
Intel® Xeon® Processor W-2155
Intel® Xeon® Processor W-2195

The processors requires a C422 chipset for full support. Just like I said back in June. I also like what Intel did – they basically renamed the E5-1600 series. Now people know what a workstation processor is, but the Intel product specifications however still mentions: “Vertical Segment Server” and that is confusing.

Edit: There are no power management resource plists for the Xeon W processors, not even in DP-8. That also means, probably, that the board-id that I used back in June, is wrong. I think that we will find a new one some day soon.

Note: The references to Purley in the firmware were a bit puzzling, but they seem to share the same Intel source code.

Yah! Gigabyte said to provide me with a motherboard for this processor line, and Intel will ship two processors next Monday!

User Approved Kernel Extension Loading…

Apple is trying to improve security on the Mac, and starting with macOS High Sierra,
kernel extensions that are installed with or after the installation of macOS High Sierra, will require user consent in order to load signed kernel extensions. This new feature should also make us more aware about the kernel extensions that we have installed. Some of which we may no longer need. After all. Not every uninstaller does what it should do.

Ok. Let me start with an example:
kextload user consent dialog
This is what I got when I tried to load the Intel kernel extension (with sudo kextload EnergyDriver.kext) from a terminal window.

Please note that there is nothing wrong with this extension. It simply wasn’t there, because I did a fresh installation of macOS High Sierra (a Developer Beta) and thus I had to allow it.

Anyway. Let’s have a look at the updated Security and Privacy preference panel, with a new button to allow blocked kernel extension. Here it is:
Security and Privacy pref panel with allow button

It shows you the name of the developer. In this example it’s one from ‘Intel Corporation Apps’. And when you ‘Allow’ a blocked kernel extension, then the entry in the SQL database (KextPolicy) for this developer (per TeamID) will be updated accordantly.

Ok. Everything so far should be clear. Oh. One more thing. This feature is also known as User Approved Kernel Extension Loading. And any user can approve a kernel extension, even one without administrator privileges. Wait. What? Yup. Read this:

Kernel extensions don’t require authorization if they:

    Were on the Mac before the upgrade to macOS High Sierra.
    Are replacing previously approved extensions.

This also explains why I had to allow the Intel kernel extension. Because it wasn’t there before, and I had not approved it already. You may now wonder if we can we disable this new feature. No worries. You can. Here’s what Apple has to say about disabling this feature:

If you want to disable User Approved Kernel Extension Loading, boot into macOS Recovery and use the spctl command. Run the command by itself to get more information about how to use the spctl command.

That’s it. You’re on your own. There is no detailed information about what you can, should and should not (try to) do. Great.

Let’s start with the output of it

Apple-iMacPro:~ Apple$ spctl

System Policy Basic Usage:
     spctl --assess [--type type] [-v] path ... # assessment
     spctl --add [--type type] [--path|--requirement|--anchor|--hash] spec ... # add rule(s)
     spctl [--enable|--disable|--remove] [--type type] [--path|--requirement|--anchor|--hash|--rule] spec # change rule(s)
     spctl --status | --master-enable | --master-disable # system master switch

Kernel Extension User Consent Usage:
     spctl kext-consent ** Modifications only available in Recovery OS **
     status
          Print whether kernel extension user consent is enabled or disabled.
     enable
          Enable requiring user consent for kernel extensions.
     disable
          Disable requiring user consent for kernel extensions.
     add
          Insert a new Team Identifier into the list allowed to load kernel extensions without user consent.
     list
          Print the list of Team Identifiers allowed to load without user consent.
     remove
          Remove a Team Identifier from the list allowed to load kernel extensions without user consent.
Apple-iMacPro:~ Apple$ spctl kext-consent status

Kernel Extension User Consent: ENABLED

Apple-iMacPro:~ Apple$ spctl kext-consent disable

spctl: failed to store new configuration.

Apple-iMacPro:~ Apple$ sudo spctl kext-consent disable

Kernel Extension User Consent: DISABLED
Please restart for changes to take effect.

Apple-iMacPro:~ Apple$ sudo spctl kext-consent enable

Kernel Extension User Consent: ENABLED
Please restart for changes to take effect.

Apple-iMacPro:~ Apple$ spctl kext-consent list

spctl: no kext consent configuration found.

Apple-iMacPro:~ Apple$ sudo spctl kext-consent add 0123456789
Apple-iMacPro:~ Apple$ spctl kext-consent list

Allowed Team Identifiers:
0123456789

Apple-iMacPro:~ Apple$ sudo spctl kext-consent remove 0123456789
Apple-iMacPro:~ Apple$ spctl kext-consent list

Locating Your Team ID

The Team ID is a unique 10+ character string generated by Apple that’s assigned to your team. You can find your Team ID using your developer account.

To locate your Team ID

Sign in to developer.apple.com/account and click Membership in the sidebar. Your Team ID appears in the Membership Information section under the team name.

NVRAM data
There are two properties that I would like to mention here. The first one being csr-active-config and the second one being csr-data. Let’s first have a look at a snippet from the output of

Apple-iMacPro:~ Apple$ nvram -xp
<key>csr-active-config</key>
<data>
gAIAAA==
</data>
<key>csr-data</key>
<data>
PGRpY3Q+PGtleT5rZXh0LWFsbG93ZWQtdGVhbXM8L2tleT48YXJyYXk+PHN0cmluZz4w
MTIzNDU2Nzg5PC9zdHJpbmc+PC9hcnJheT48L2RpY3Q+AA==
</data>
Apple-iMacPro:~ Apple$ echo -n gAIAAA==|base64 --decode|xxd -ps

0x80020000 (feature disabled)

Apple-iMacPro:~ Apple$ echo -n gAAAAA==|base64 --decode|xxd -ps

0x80000000 (feature enabled)

Note: You can use my csrstat command line tool to check the status of all SIP settings!

The base64 data of csr-data property is a dictionary with an array of all allowed team identifiers. Here is the one from our example

<dict>
    <key>kext-allowed-teams</key>
    <array>
        <string>0123456789</string>
    </array>
</dict>

And the csr-data property will still be there when you removed all team identifiers, but then with an empty array. Like this.

<dict>
    <key>kext-allowed-teams</key>
    <array>
    </array>
</dict>

Reset NVRAM will revert to its default state with User Approved Kernel Extension Loading enabled.

Enrolling in Mobile Device Management (MDM) automatically disables User Approved Kernel Extension Loading. The behavior for loading kernel extensions will be the same as macOS Sierra.

A future update to macOS High Sierra will allow you to use MDM to enable or disable User Approved Kernel Extension Loading, and to manage the list of kernel extensions which are allowed to load without user consent. If that is before or after the official release of macOS High Sierra is not known.

But you know what. All extensions in the prelinkedkernel are stripped. There is no data of the signature. Apple (still) relies on tools to check the kexts signature, before inclusion in the prelinkedkernel, and somehow, that doesn’t feel right.

Update: The configuration is stored in: /var/db/SystemPolicyConfiguration/KextPolicy. I also found the SQL statements that spctl and systempolicyd are using to initialise and update the database:

DROP TABLE IF EXISTS kext_load_history

DROP TABLE IF EXISTS kext_load_history_v2

DROP TABLE IF EXISTS policy_by_team

DROP TABLE IF EXISTS policy_by_team_v2

DROP TABLE IF EXISTS policy_by_cdhash

DROP TABLE IF EXISTS policy_by_cdhash_v2

DELETE FROM kext_policy WHERE team_id = ?1 AND bundle_id = ?2

DELETE FROM kext_load_history_v3 WHERE team_id = ?1 AND bundle_id = ?2

SELECT bundle_id, developer_name FROM kext_policy WHERE team_id IS NULL

UPDATE kext_policy SET developer_name = ?1 WHERE team_id IS NULL and bundle_id = ?2

CREATE TABLE IF NOT EXISTS kext_load_history_v3 ( path TEXT PRIMARY KEY, team_id TEXT, bundle_id TEXT, boot_uuid TEXT, created_at TEXT, last_seen TEXT, flags INTEGER )

CREATE TABLE IF NOT EXISTS kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT, flags INTEGER, PRIMARY KEY (team_id, bundle_id) )

SELECT allowed, flags FROM kext_policy WHERE team_id = ?1 AND bundle_id = ?2

SELECT allowed, flags FROM kext_policy WHERE team_id IS NULL AND bundle_id = ?2

SELECT allowed FROM kext_policy WHERE team_id = ?1", 0

INSERT INTO kext_policy (team_id, bundle_id, allowed, developer_name, flags) VALUES (?1, ?2, ?3, ?4, ?5)

UPDATE kext_policy SET allowed = ?3, flags = ((flags & ~?4) | ?5) WHERE team_id = ?1 AND bundle_id = ?2

UPDATE kext_policy SET allowed = ?3, flags = ((flags & ~?4) | ?5) WHERE team_id IS NULL AND bundle_id = ?2

UPDATE kext_policy SET flags = (flags | ?3) WHERE team_id = ?1

UPDATE kext_policy SET flags = (flags | ?3) WHERE team_id IS NULL AND bundle_id = ?2

SELECT 1 FROM kext_load_history_v3 WHERE path = ?1

SELECT flags FROM kext_load_history_v3 WHERE path = ?1

UPDATE kext_load_history_v3 SET team_id = ?2, bundle_id = ?3, flags = ?4, last_seen = datetime('now') WHERE path = ?1

INSERT INTO kext_load_history_v3 (path, team_id, bundle_id, boot_uuid, created_at, last_seen, flags) VALUES (?1, ?2, ?3, ?4, datetime('now'), datetime('now'), ?7)

SELECT created_at FROM kext_load_history_v3 WHERE team_id = ?1 AND bundle_id = ?2

SELECT created_at FROM kext_load_history_v3 WHERE team_id IS NULL AND bundle_id = ?2

SELECT last_seen FROM kext_load_history_v3 WHERE team_id = ?1 AND bundle_id = ?2

SELECT last_seen FROM kext_load_history_v3 WHERE team_id IS NULL AND bundle_id = ?2

SELECT 1 FROM kext_load_history_v3 WHERE team_id = ?1 AND bundle_id = ?2 AND (flags & ?3) = ?3 AND boot_uuid != ?4

SELECT 1 FROM kext_load_history_v3 WHERE team_id IS NULL AND bundle_id = ?2 AND (flags & ?3) = ?3 AND boot_uuid != ?4

SELECT DISTINCT team_id FROM kext_policy WHERE team_id IS NOT NULL

SELECT bundle_id, developer_name, allowed FROM kext_policy WHERE team_id = ?1

SELECT bundle_id, developer_name, allowed FROM kext_policy WHERE team_id IS NULL

SELECT path, flags FROM kext_load_history_v3 WHERE team_id = ?1 AND bundle_id = ?2

SELECT path, flags FROM kext_load_history_v3 WHERE team_id IS NULL AND bundle_id = ?2

SELECT 1 FROM kext_policy WHERE flags & ?1 = ?1

UPDATE kext_policy SET allowed = 0, flags = ((flags & ~?1) | ?2) WHERE allowed = 1

You can use the above SQL statements with either /usr/bin/sqlite3 or some GUI app. Here is an example of the KextPolicy database:
Image of KextPolicy database

Edit: The SQL database has two tables (kext_load_history_v3 and kext_policy). Let’s get going:

1.) open a terminal window and enter:

/usr/bin/sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy

2.) Enter:

sqlite> .tables

The result should be: kext_load_history_v3, kext_policy The two tables in the policy database.

We’re now going to get some data from the database. Enter one, or both, of the following SQL statements:

sqlite> SELECT path, bundle_id, team_id, boot_uuid, created_at, last_seen, flags FROM kext_load_history_v3;

Result:

/Library/Extensions/CIJUSBLoad.kext|jp.co.canon.ij.print.CIJUSBLoad|XE2XNRRXZ5|D2E6A228-1C85-4138-9CC5-253105DF1BDC|2017-08-31 10:58:46|2017-09-01 13:45:49|9
/Library/Extensions/BJUSBLoad.kext|jp.co.canon.bj.print.BJUSBLoad|XE2XNRRXZ5|D2E6A228-1C85-4138-9CC5-253105DF1BDC|2017-08-31 10:58:46|2017-09-01 13:45:49|1
/Library/Extensions/EnergyDriver.kext|com.intel.driver.EnergyDriver|Z3L495V9L4|D4829428-7105-425D-830E-A69DCAADD558|2017-09-01 13:30:23|2017-09-01 13:34:41|1
/Applications/Intel Power Gadget/EnergyDriver.kext|com.intel.driver.EnergyDriver|Z3L495V9L4|D4829428-7105-425D-830E-A69DCAADD558|2017-09-01 13:34:52|2017-09-01 13:55:30|5

Or just:

SELECT * FROM kext_load_history_v3;

Giving you the same output. Let’s do that for the policy table as well.

3.) Enter:

sqlite> SELECT team_id, bundle_id, allowed, developer_name, flags FROM kext_policy;

Result:

XE2XNRRXZ5|jp.co.canon.bj.print.BJUSBLoad|1|Canon Inc.|0
XE2XNRRXZ5|jp.co.canon.ij.print.CIJUSBLoad|1|Canon Inc.|0
Z3L495V9L4|com.intel.driver.EnergyDriver|1|Intel Corporation Apps|1

Or just:

SELECT * FROM kext_policy;

Again. Giving you the same kind of output. And with this information we can delete the history of a kext. Let’s do that for the Intel EnergyDriver.kext If you do not have this driver installed, then just pick another.

4.) Enter:

sqlite> DELETE FROM kext_load_history_v3 WHERE team_id = 'Z3L495V9L4';

Done. Let’s also delete the policy for this kext.

5.) Enter:

sqlite> DELETE FROM kext_policy WHERE team_id = 'Z3L495V9L4';

Please note that I used the team_id in my examples, but you can also use the bundle_id or developer_name.

6.) you can now exit sqlite3 by entering:

.quit

Currently there is (still) no formal way to change the data, but that should change in a future update of High Sierra.

Please note that you can only change the data from the RecoveryOS. Please do not mess with the data. This is just a reference for developers and hackers alike. This is not intended for end users!

p.s. I love this one:

You can set a firmware password on your Mac to prevent unauthorized changes to NVRAM.

Yes. You better do that. Or wait. Just look at that command prompt (Apple-iMacPro:~ Apple) showing you that I changed the setting from a macOS High Sierra terminal window, as administrator 🙂

BUG… BUG… BUGREPORTER !!!

New HandyScript called installSeed.py

You may have used one of my HandyScripts to install High Sierra. The problem with these scripts was that I had to update them for every new Developer Preview. And that was a burden. Taking too much time, and that is why I converted the bash scripts to a much smarter python variant. I started to work on it back in July, but it is still ugly, and I had never used it. Not until today.

Update: installSeed.py v1.7 includes bug fixes so you better use the latest version!

Updates: installSeed.py v1.8 is now available. This update downloads the correct i18n dictionary.
installSeed.py v1.9 is now available. This update includes minor cleanups and a version number error fix.
installSeed.py v2.0 is now available. This update exits gracefully, with instructions to install pip/request module.

Anyway. We first have to make some preparations. Open a terminal window and enter:

sudo easy_install pip
sudo pip install requests

That should get you ready for installSeed.py. The output of installSeed.py is pretty much similar to that of the previous bash scripts:

Available target volumes:

[ 0 ] MackintoshHD
[ 1 ] High Sierra

Select a target volume for the boot file: 1
Seed Program Enrollment: DeveloperSeed
File: BaseSystem.chunklist already there, skipping this download.
File: InstallESDDmg.pkg already there, skipping this download.
File: InstallAssistantAuto.pkg already there, skipping this download.
File: AppleDiagnostics.chunklist already there, skipping this download.
File: InstallESDDmg.chunklist already there, skipping this download.
File: OSInstall.mpkg already there, skipping this download.
File: InstallInfo.plist already there, skipping this download.
File: RecoveryHDMetaDmg.pkg already there, skipping this download.
File: BaseSystem.dmg already there, skipping this download.
File: AppleDiagnostics.dmg already there, skipping this download.
Creating installer.pkg ...
productbuild: Wrote product to /Volumes/High Sierra/tmp/091-30125/installer.pkg
Running installer ...
Password:
installer: Package name is Install macOS High Sierra Beta
installer: Installing at base path /Volumes/High Sierra
installer: The install was successful.
Copying: InstallESDDmg.pkg to the target location ...
Copying: AppleDiagnostics.dmg to the target location ...
Copying: AppleDiagnostics.chunklist to the target location ...
Copying: BaseSystem.dmg to the target location ...
Copying: BaseSystem.chunklist to the target location ..

The good thing (for me) is that with the introduction of installSeed.py I no longer need to update the file for every new Developer Preview.

Oh. One last note. The file /Users/Shared/.SeedEnrollment.plist should be this:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>SeedProgram</key>
		<string>DeveloperSeed</string>
	</dict>
</plist>

If you have a backslash in the first line, then please remove it before running installSeed.py

Have fun!