Hello!
I've just recently discovered LaunchCodeRequirement API and I'm exploring how it works compared to existing alternatives available for macOS versions below 14.4.
Some questions I have with regards to safety of older and newer APIs examining the given example:
func runProcess(executableURL: URL) throws {
let process = Process()
process.executableURL = executableURL
if #available(macOS 14.4, *) {
process.launchRequirement = try LaunchCodeRequirement.allOf {
ValidationCategory(.developerID)
SigningIdentifier("some-signing-identifier")
TeamIdentifier("some-team-identifier")
}
} else {
try secStaticCodeCheckValidity(executableURL) // Point #1
}
do {
try process.run() // Point #2
if #available(macOS 14.4, *) {
// process.launchRequirement should take care of the process
// and kill it if launchRequirement constraint is not satisfied
} else {
try secCodeCheckValidity(process.processIdentifier) // Point #3
}
process.waitUntilExit()
} catch {
process.terminate()
throw error
}
// Point #4
guard process.terminationReason == .exit else {
throw SomeError()
}
}
let requirement =
"""
anchor apple generic
and identifier = "some-signing-identifier"
and certificate 1[field.1.2.840.113635.100.6.2.6]
and certificate leaf[field.1.2.840.113635.100.6.1.13]
and certificate leaf [subject.OU] = "some-team-identifier"
"""
func secStaticCodeCheckValidity(_ executableURL: URL) throws {
// Init SecStaticCode from `executableURL`
// Init SecRequirement from `requirement`
let flags = SecCSFlags(rawValue: kSecCSBasicValidateOnly)
guard SecStaticCodeCheckValidityWithErrors(code, flags, secRequirement, nil) == errSecSuccess else {
throw CodeSignError()
}
}
func secCodeCheckValidity(_ processIdentifier: Int32) {
// Init SecCode from `processIdentifier`
// Init SecRequirement from `requirement`
guard SecCodeCheckValidityWithErrors(code, [], secRequirement, nil) == errSecSuccess else {
throw CodeSignError()
}
}
Before macOS 14.4+ flow
There's still a small chance that between checking executable binary codesign requirement (Point #1) and launched process' one (Point #3) the binary could be replaced with something malicious and even get some CPU between Points #2 and #3 so technically it can't be 100% safe. Is that a correct statement? Any advices on making it safer?
macOS 14.4+ flow
Now let's see how launchRequirement is better. I guess initialized launchRequirement gets evaluated on running the process (Point #2).
What does it exactly check? Executable at URL before launching the process (as OnDiskConstraint) or launched process (as ProcessConstraint)?
Is there any chance the process gets some CPU before it's killed in case of failed codesign check?
Any way to distinguish between codesign requirement termination and other reasons at point #4? It returns SIGKILL (9) as terminationStatus but it's not precise enough to be sure it was killed due to failed requirement check. I guess newer SecStaticCodeCheckValidityWithOnDiskRequirement & SecCodeCheckValidityWithProcessRequirement are the same as SecStaticCodeCheckValidityWithErrors & SecCodeCheckValidityWithErrors but a little simpler and can't be used as a 'more secure' way of validating codesign requirement.
Thanks,
Pavel
Topic:
Code Signing
SubTopic:
General