search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
3.05k stars 422 forks source link

Mutable macOS App names causing inconsistencies #22994

Open mostlikelee opened 1 day ago

mostlikelee commented 1 day ago

Fleet version: 4.47.0

Web browser and operating system: All

💥  Actual behavior

Fleet currently uses the name column from the osquery apps table to identify application names using the file name of the app bundle.

This can be a problem, as any end user account with admin rights can rename almost any filename on a macOS device resulting in:

🧑‍💻  Steps to reproduce

  1. Install Google Chrome on macOS
  2. Rename /Applications/Google Chrome.app to /Applications/Foo.app
  3. Run vulnerability scan, confirm no Google Chrome vulnerabilities
  4. Upload Google Chrome package to software

  5. Uploaded software is now named "Foo"

    🛠️ To fix

    While the problems above are slightly different, I believe we can achieve consistent results in both cases by using the bundle_executable osquery column, which sources from the CFBundleExecutable attribute from /Appname.app/Contents/Info.plist.

This change will require some updates to vulnerability rules that key off of the existing name column.

mostlikelee commented 1 day ago

@nonpunctual curious what you think

nonpunctual commented 1 day ago

@mostlikelee @allenhouchins @ddribeiro @dherder @noahtalerman @marko-lisica @lukeheath

In Jamf, uploaded packages have 2 names:

  1. the "filename" i.e. whatever the unix file system name the package file has on the computer uploading to the package repo.
  2. the "display" name, i.e., whatever crazy label you want to give it in the Jamf UI so that it makes sense for admin users.

I kind of think this is a good system. The reason it works is because in the Jamf db (as it were, on the backend) the package is probably always referred to by its object type <package> & its index, or by some given UUID in use, not by its name.

However, that does not prevent collisions on upload. Jamf Admin for years had an unresolved bug around uploading packages with the same names colliding, which is why I always added date strings to my package names e.g. 20241017 Adobe blah.app & if I had to upload the same package because something went wrong I would usually uptick the day.

The "most" immutable & consistent attribute of any app is going to be the bundle identifier. I agree that name is bad if we are relying on it. We shouldn't. It's a mutable string, so just let it be that? If we are going to insist on inspection inside the package instead of allowing the users to name things as they wish, then we should be getting & using the bundle ID + short version + upload date / time for everything imo, or, figure out a way to give packages a UUID or an index on successful upload so that each package has a unique identifier in the Fleet backend.