Post

Replies

Boosts

Views

Activity

Installing a endpoint security system extension with MDM results in application code signing being modified
I am posting here as I am a loss for what to try next. I want to remotely install an application with an endpoint security system extension using my MDM (MicroMDM). To do this, I am sending an InstallEnterpriseApplication command to my MDM server to install an application containing a system extension with an endpoint security entitlement. The application installs without error according to install.log. However, when I inspect the app that was installed, its contents have been modified. This breaks codesigning and the application cannot load the endpoint security system extension anymore. HOWEVER, when I take the exact same installer.pkg and double click it from Finder to manually install it by hand, the resulting application is unmodified and as expected! I know the MDM server isn't modifying the application because when I download the installer from the URL that's in my manifest and hash it, the hash matches the original installer file I had before I uploaded it to my MDM. Is there an issue with MDMs installing applications with system extensions/endpoint security entitlement? I know this is not an issue with my codesigning or packaging because everything works fine when I double click the package installer and install it by hand. Has anyone run into this? Here is my manifest.plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>items</key> <array> <dict> <key>assets</key> <array> <dict> <key>kind</key> <string>software-package</string> <key>md5-size</key> <integer>10485760</integer> <key>md5s</key> <array> <string>HASH1</string> <string>HASH2</string> <string>HASH3</string> </array> <key>url</key> <string>https://mdm-testing.sys/repo/installer.pkg</string> </dict> </array> </dict> </array> </dict> </plist>
1
0
1.1k
Jun ’22
System Extension and LC_CTYPE?
Is it possible to set LC_CTYPE in a System Extension? I am running into issues with vswprintf due to what I presume are locale-related issues. The errno that vswprintf sets is EILSEQ. In a brand new program (not system extension), vswprintf fails with EILSEQ if LC_CTYPE is not set, but it does work when LC_CTYPE is set with something like setlocale(LC_CTYPE, "UTF-8"). The difference is that in a system extension, the setlocale() seems to make no difference. Is there another way to set LC_CTYPE for a system extension? Is it not possible to use vswprintf within a system extension?
1
0
550
Dec ’21
Empty DynamicData directory in Big Sur
On a Big Sur host bound to Active Directory, I am seeing some hosts with an empty /Library/Preferences/OpenDirectory/DynamicData directory. Output of dsconfigad -show seems to be good and consistent with other hosts that have data inside the DynamicData directory. The directory at /Library/Preferences/OpenDirectory/Configurations is never empty for any host and data looks okay. I am not able to reproduce this on a local Big Sur host I have that is also bound to Active Directory using Directory Utility. My question is: Are there scenarios in which the DynamicData directory would be empty?
1
0
739
Mar ’21