KextPolicy Database flags

Questions and Answers about all things *OS (macOS, iOS, tvOS, watchOS)

KextPolicy Database flags

Postby TheDarkKnight » Tue Aug 28, 2018 4:02 pm

The KextPolicy database, located at /var/db/SystemPolicyConfiguration/KextPolicy contains the kext_policy table.
One of the fields in that table is 'flags', but I can't seem to find what the values represent when searching through Apple's 10.13 source.

Does anyone know what each of the flag options in this table represents?

Thanks ;O)
Posts: 38
Joined: Wed Dec 16, 2015 10:30 am

Re: KextPolicy Database flags

Postby morpheus » Tue Aug 28, 2018 9:13 pm

Haven't looked into it myself, but it won't be in the sources due to /usr/libexec/syspolicyd , a closed source project, being the one to perform queries and SELECT/UPDATE these flags. These flags are also in the kext_load_history_v3 btw. The flags I'm seeing are:

Code: Select all
bash-3.2# sqlite3 -header  KextPolicy "select * from kext_policy"
EG7KH642X6|com.vmware.kext.vmnet|1|VMware, Inc.|8
EG7KH642X6|com.vmware.kext.vmci|1|VMware, Inc.|8
EG7KH642X6|com.vmware.kext.vmx86|1|VMware, Inc.|8
EG7KH642X6|com.vmware.kext.vmioplug.15.2.1|1|VMware, Inc.|8

Without looking into syspolicyd, I'll wager at least one of the flags is allowed by legacy (as in, existing pre upgrade to 13+).
Site Admin
Posts: 694
Joined: Thu Apr 11, 2013 6:24 pm

Re: KextPolicy Database flags

Postby TheDarkKnight » Wed Aug 29, 2018 9:55 am

I'll wager at least one of the flags is allowed by legacy (as in, existing pre upgrade to 13+).

That would make sense.

We have one machine that refuses to load our kext when SIP is enabled, due to how it copies it to the Staging area. The same kext works on all other machines and VMs, so I'm trying to understand what is causing this one machine to fail. Deleting the entries in the db for the kext causes it to prompt the user again for authorisation, but it still fails to load successfully, so I wondered if those flags were related.

A discussion on the kext loading / staging system would be a great addition to Volume II ;)

After a little more research, it seems the error we're seeing
Kext rejected due to insecure location

comes from security.c of the kext_tools source, so I think I need to focus on identifying what is classed as a "secure location"; it seems strange that the location it states is insecure is under /Library/StagedExtensions, which is where it has copied our kext. The full path, for example, being


From staging.m

Code: Select all
pathIsSecure(NSString *path) {
    Boolean is_secure = false;
    BOOL is_protected_volume = rootless_protected_volume(path.UTF8String) ? YES : NO;
    BOOL is_trusted_path = rootless_check_trusted_class(path.UTF8String, "KernelExtensionManagement") == 0 ? YES : NO;

    if (isSIPDisabled()) {
        // SIP is disabled so everything is considered secure.
        is_secure = true;
    } else if (!is_protected_volume) {
        // SIP is enabled and the volume is not protected, so it's insecure.
        is_secure = false;
    } else {
        // SIP is enabled and it is a protected volume, so it's only secure if it's trusted.
        is_secure = is_trusted_path;
    return is_secure;

Perhaps is_protected_volume is failing, though the volume states that it is supported.

Thanks ;O)
Posts: 38
Joined: Wed Dec 16, 2015 10:30 am

Return to Questions and Answers

Who is online

Users browsing this forum: No registered users and 4 guests