Update `safari_extensions` table to support modern Safari App Extensions

Feature request

What new feature do you want?

This is a request to update the safari_extensions table to support the modern "Safari App Extension" format on recent versions of macOS.

Currently, the safari_extensions table returns an empty result on macOS because Apple has deprecated the old extension format that the table was designed to query. Modern Safari extensions are now bundled within applications (.appex files) and are not detected by the existing logic.

For example, running SELECT * FROM safari_extensions; on a device with extensions installed yields nothing, even though chrome_extensions and firefox_addons work as expected. The feature is to restore the intended functionality of this table for modern Safari versions.

How is this new feature useful?

This feature is critical for maintaining security and compliance visibility on macOS endpoints. Without a functioning safari_extensions table, administrators and security teams have a significant blind spot and cannot audit the browser extensions installed in Safari.

The primary use case is to allow security teams to run queries to enumerate all installed Safari extensions across their fleet of macOS devices. This allows them to:

• Identify potentially malicious or unwanted extensions.
• Ensure compliance with organizational policies regarding browser add-ons.
• Maintain feature parity with osquery's auditing capabilities for other browsers like Chrome and Firefox.

Restoring this functionality makes osquery a more complete and reliable tool for macOS security monitoring.

How can this be implemented?

Implementation will require updating the table's logic to account for the new Safari App Extension architecture. Based on previous investigation, here are the likely steps:

1. Update Data Source Logic: The table needs to be taught where to find the new extension data. This could involve:

   • Parsing the Extensions.plist file, which can be found at ~/Library/Containers/com.apple.Safari/Data/Library/Safari/AppExtensions/Extensions.plist.
   • Alternatively, or in addition, scanning application directories (e.g., /Applications/) for .appex bundles and parsing their Info.plist files for metadata. An example location is /Applications/1Password.app/Contents/PlugIns/1PasswordSafariAppExtension.appex.

2. Address Permissions: Accessing these files requires Full Disk Access (FDA) for the osquery agent. The implementation should be done with this requirement in mind.

3. Update Documentation: The osquery documentation for the safari_extensions table must be updated to clearly state the FDA requirement. It should provide guidance for administrators on how to grant this permission, for example, by deploying a Privacy Preferences Policy Control (PPPC) payload using an MDM solution to authorize the osquery executable.

Start with the existing safari_extensions table logic and compare it with the modern paths named in the issue: Extensions.plist and .appex bundles such as /Applications/1Password.app/Contents/PlugIns/1PasswordSafariAppExtension.appex. Validate the result with SELECT * FROM safari_extensions on macOS, and update the table documentation with the Full Disk Access and PPPC guidance described here.