Fleet versions
- Discovered: 4.84.2
- Reproduced: 4.84.3
Web browser and operating system: N/A
💥 Actual behavior
A Fleet premium customer from the community is using Fleet to deploy XCreds. They uploaded the XCreds.pkg as a custom package to their Fleet server and used the "Automatic deploy" option.
The policy that Fleet created used an incorrect bundle identifier, which would always cause the generated policy to fail. It would never pass, even after the software has correctly been installed. Here is the policy that Fleet generates:
SELECT 1 FROM apps WHERE bundle_identifier = 'com.twocanoes.pkg.secureremoteaccess';
But the CFBundleIdentifier from XCred's Info.plist file is com.twocanoes.xcreds, which is what osquery reads from.
🛠️ Expected behavior
The identifier that Fleet uses in the automatically generated policy should match the identifier that osquery reports for in the bundle_identifier column in the apps table.
🧑💻 Steps to reproduce
These steps:
- Obtain the XCreds installer from the Twocanoes website.
- Upload
XCreds.pkg to your Fleet server and make sure the "Deploy" toggle is enabled, so Fleet will automatically generate an install policy for the software.
- Observe the Fleet generated policy uses
com.twocanoes.pkg.secureremoteaccess.
- Install XCreds on your test system. Run
SELECT bundle_identifier FROM apps; on your test system. Observe the osquery reported bundle_identifier is com.twocanoes.xcreds
🕯️ More info (optional)
This is because Fleet is using 2 different namespaces to generate the policy and detect when it's installed. Upon upload, Fleet is checking the pkg install identifier from pkgbuild --identifier but osquery is using the CFBundleIdentifier from Info.plist. These namespaces are often the same, but not guaranteed to be.
Fleet versions
Web browser and operating system: N/A
💥 Actual behavior
A Fleet premium customer from the community is using Fleet to deploy XCreds. They uploaded the
XCreds.pkgas a custom package to their Fleet server and used the "Automatic deploy" option.The policy that Fleet created used an incorrect bundle identifier, which would always cause the generated policy to fail. It would never pass, even after the software has correctly been installed. Here is the policy that Fleet generates:
SELECT 1 FROM apps WHERE bundle_identifier = 'com.twocanoes.pkg.secureremoteaccess';But the
CFBundleIdentifierfrom XCred's Info.plist file iscom.twocanoes.xcreds, which is what osquery reads from.🛠️ Expected behavior
The identifier that Fleet uses in the automatically generated policy should match the identifier that osquery reports for in the
bundle_identifiercolumn in theappstable.🧑💻 Steps to reproduce
These steps:
XCreds.pkgto your Fleet server and make sure the "Deploy" toggle is enabled, so Fleet will automatically generate an install policy for the software.com.twocanoes.pkg.secureremoteaccess.SELECT bundle_identifier FROM apps;on your test system. Observe the osquery reported bundle_identifier iscom.twocanoes.xcreds🕯️ More info (optional)
This is because Fleet is using 2 different namespaces to generate the policy and detect when it's installed. Upon upload, Fleet is checking the pkg install identifier from
pkgbuild --identifierbut osquery is using theCFBundleIdentifierfrom Info.plist. These namespaces are often the same, but not guaranteed to be.