[macOS][packaging] Create an app bundle along with other package_data by sharvil...
source link: https://github.com/osquery/osquery/pull/7263
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Create an app bundle structure along side the other package_data
➜ osquery git:(macos_app_bundle_package_data) pwd
/Users/sharvil/code/osquery/build/package_data/opt/osquery
➜ osquery git:(macos_app_bundle_package_data) tree
.
├── bin
│ ├── osqueryctl
│ ├── osqueryd
│ └── osqueryi -> osqueryd
└── osquery.app
└── Contents
├── Info.plist
├── MacOS
│ └── osqueryd
├── PkgInfo
├── Resources
│ └── osqueryctl
└── embedded.provisionprofile
5 directories, 8 files
@directionless this creates a simple app structure alongside the other package_data
Updating the packaging repo next
Can we have it so that the osqueryd binary is only installed into the app bundle?
Can we have it so that the osqueryd binary is only installed into the app bundle?
I'm good either way, but I want to note that if we do that, end users will not be able to get a bare signed osqueryd. Only the app bundle. (Moving the binary out invalidates the signature)
Can we have it so that the osqueryd binary is only installed into the app bundle?
Yeah, we can just remove the earlier install directive here
install(
TARGETS osqueryd
DESTINATION "bin"
)
But as per @alessandrogario's comment, I am keeping most of package_data consistent across platforms, but just dropping the app bundle alongside on macOS. I am also good either way
Where is the signature data stored when you sign an app bundle?
Is it possible to sign the binary, then sign the outer app bundle?
Is it possible to sign the binary, then sign the outer app bundle?
Yes that is possible. You probably want to have identifier org.osquery.osquery for the app bundle, and org.osquery.osquery.daemon for the binary.
Where is the signature data stored when you sign an app bundle?
Is it possible to sign the binary, then sign the outer app bundle?
For the .app bundle it's stored in _CodeSignature/CodeResources inside the app bundle, this gets created when codesign is run. For the binary it's stored inside the Mach-O segment
Is it possible to sign the binary, then sign the outer app bundle?
yep, @directionless already did that
Is it possible to sign the binary, then sign the outer app bundle?
I don't think so. I think the outer signature overwrites the inner. Using one of the app bundles from a CI build (ignore the notarization errors)
# Existing sig, invalid in app bundle, valid outside it: $ /usr/sbin/spctl -a -vvv --ignore-cache osquery.app/Contents/MacOS/osqueryd osquery.app/Contents/MacOS/osqueryd: code has no resources but signature indicates they must be present $ cp osquery.app/Contents/MacOS/osqueryd osquery-one $ /usr/sbin/spctl -a -vvv --ignore-cache osquery-one osquery-one: rejected source=Unnotarized Developer ID origin=Developer ID Application: OSQUERY A Series of LF Projects, LLC (3522FA9PXF) # signed app bundle, valid inside but not outside: $ codesign -s "3522FA9PXF" --force --entitlements /tmp/pd/control/osquery.entitlements --options runtime -v --timestamp osquery.app osquery.app: replacing existing signature osquery.app: signed app bundle with Mach-O thin (x86_64) [io.osquery.agent] $ /usr/sbin/spctl -a -vvv --ignore-cache osquery.app/Contents/MacOS/osqueryd osquery.app/Contents/MacOS/osqueryd: accepted source=Notarized Developer ID origin=Developer ID Application: OSQUERY A Series of LF Projects, LLC (3522FA9PXF) $ cp osquery.app/Contents/MacOS/osqueryd osquery-two $ /usr/sbin/spctl -a -vvv --ignore-cache osquery-two osquery-two: invalid resource directory (directory or signature have been modified)
I'm not sure how many people want a bare macho binary. My gut sense is that that's only something wanted by some vendors. I'm willing to ship both, or just the .app
Notarization is for apps, so spctl -a should fail when checking the binary outside of the notarized app folder.
However, the codesign -dvvv on the binary should be valid even if copied outside to another location.
Vendors could copy osqueryd from official releases inside their own app bundle and get it notarized.
To summarize, if you release just the notarized osquery .app, it should work for everyone, as long as the binaries inside are code signed as well.
Notarization is for apps, so
spctl -ashould fail when checking the binary outside of the notarized app folder.
No, this is not correct. macho binaries, when then have the quarantine bit set, also must be notarized. My example showed notarization errors, because I didn't want to submit them to apple and wait for the test case. The plain signature was enough to show what was happening.
I don't think the codesign -dvvv output is easy to read, and IMO tends to mask errors. But the -vvv output:
$ codesign -vvv osquery-one
osquery-one: valid on disk
osquery-one: satisfies its Designated Requirement
$ codesign -vvv osquery-two
osquery-two: invalid Info.plist (plist or signature have been modified)
In architecture: x86_64
Does this need the sha from osquery/osquery-packaging#11 ?
Yeah, I can change it here, give me a minute.
As I just commented in slack:
So, conclusion from office hours:
- We should ship a signed .app. This is what should be in the pkg. This is the expected and common path
- There are some folks who use bare macho binaries. Both Kolide and Fleet, for example. While both of us can sign binaries ourselves. I think there’s some value in shipping an osquery signed one. Specifically because I’m seeing some other vendors ship modified osquery binaries and claim it’s stock. So I want a better chain of custody,
- A shipped, bare, macho binary should not be in the pkg, and should not be an obvious download from the downloads section of the website. It is very much an advanced tool, akin to the debugging symbols.
I’m not sure what that means for the existing PRs sharvil has in flight. I’m not sure osqueryd should be in package-data/opt/osquery/bin/osqueryd, since that should be the symlink. I think there’s some nonsense to work through
Thumbing this along the way. There may be more changes needed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK