Killed -9 when running app signed with endpoint security

Question

Created Apr ’22

Replies 3

Boosts 0

Views 2.4k

Participants 2

If I run this application from my home developer directory, it doesn't have a problem. When, however, I copy it to /Library/Application Support/Fidelis..., then I immediately get "killed -9"

./protect_am
Killed: 9

I have this code structure:

ProtectOnAccess.app/
ProtectOnAccess.app//Contents
ProtectOnAccess.app//Contents/_CodeSignature
ProtectOnAccess.app//Contents/_CodeSignature/CodeResources
ProtectOnAccess.app//Contents/_CodeSignature/CodeDirectory
ProtectOnAccess.app//Contents/_CodeSignature/CodeRequirements-1
ProtectOnAccess.app//Contents/_CodeSignature/CodeSignature
ProtectOnAccess.app//Contents/_CodeSignature/CodeRequirements
ProtectOnAccess.app//Contents/MacOS
ProtectOnAccess.app//Contents/MacOS/protect_am
ProtectOnAccess.app//Contents/Resources
ProtectOnAccess.app//Contents/Resources/Info.plist
ProtectOnAccess.app//Contents/embedded.provisionprofile
ProtectOnAccess.app//Contents/Info.plist
ProtectOnAccess.app//Contents/PkgInfo

and ./protect_am is a symbolic link as follows:

lrwxr-xr-x   1 root  wheel    45B Apr 27 14:52 protect_am -> ProtectOnAccess.app/Contents/MacOS/protect_am

The thing is, I have had this work at times. No idea what the problem is. Log stream isn't helping

codesign -vvvv protect_am
protect_am: valid on disk
protect_am: satisfies its Designated Requirement

codesign -vvvv ProtectOnAccess.app/
--prepared:/Library/Application Support/Fidelis/Endpoint/Platform/services/protect/ProtectOnAccess.app/Contents/MacOS/protect_am
--validated:/Library/Application Support/Fidelis/Endpoint/Platform/services/protect/ProtectOnAccess.app/Contents/MacOS/protect_am
ProtectOnAccess.app/: valid on disk
ProtectOnAccess.app/: satisfies its Designated Requirement

Now, I do have entitlements added only to the executable, not to the .app.

codesign -d --entitlements :- ProtectOnAccess.app/Contents/MacOS/protect_am
Executable=/Library/Application Support/Fidelis/Endpoint/Platform/services/protect/ProtectOnAccess.app/Contents/MacOS/protect_am
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>com.apple.application-identifier</key>
        <string>AMLU******.Fidelis.protect-am</string>
        <key>com.apple.developer.endpoint-security.client</key>
        <true/>
        <key>com.apple.developer.team-identifier</key>
        <string>AMLU******</string>
        <key>com.apple.security.cs.allow-jit</key>
        <true/>
</dict>
</plist>

I would like to know what I'm doing wrong, and what I have accidentally done right from time to time to have it work.

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’22

Two things…

How are you copying your code? It’s possible you’re being bitten by the issue discussed in Updating Mac Software.

Is protect_am a Mach-O executable? Because this seems wonky:

ProtectOnAccess.app//Contents/_CodeSignature/CodeDirectory

It indicates that codesign stored your code directory outside the bundle’s main executable, and that’s not what I’d expect in this situation.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

DTS Engineer OP

Apple

Apr ’22

I think this would definitely not cause the issue discussed in that post about updating mac software.

cp is a prime offender in this issue. Consider this:

% cp -r /Applications/QProcessDock.app .
% ls -i QProcessDock.app/Contents/MacOS/QProcessDock 
108635450 QProcessDock.app/Contents/MacOS/QProcessDock
% cp -r /Applications/QProcessDock.app .            
% ls -i QProcessDock.app/Contents/MacOS/QProcessDock
108635450 QProcessDock.app/Contents/MacOS/QProcessDock

The second cp overwrote the QProcessDock file in place — there’s no change of inode number — and that’s exactly what triggers this issue.

If you stick with cp, you must remove the executable beforehand:

% rm -r QProcessDock.app                            
% cp -r /Applications/QProcessDock.app .            
% ls -i QProcessDock.app/Contents/MacOS/QProcessDock
108635531 QProcessDock.app/Contents/MacOS/QProcessDock

Now you get a new inode number, which is what you want.

Should I delete the _CodeSignature directory?

No. The presence of the CodeDirectory file, along with the fact that protect_am is a Mach-O executable, suggests deeper problems. Normally codesign will place the code directory for a bundle in that bundle’s main Mach-O image. You have a bundle, and a Mach-O image, but the signature isn’t going in there. That’s suggests that codesign is confused as to the structure of your bundle.

Are you sure that the CFBundleExecutable property is your Info.plist references protect_am?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

Darrilla OP

Apr ’22

I have this working now. First, I changed my code structure:

ProtectOnAccess.app
ProtectOnAccess.app/Contents
ProtectOnAccess.app/Contents/_CodeSignature
ProtectOnAccess.app/Contents/_CodeSignature/CodeResources
ProtectOnAccess.app/Contents/MacOS
ProtectOnAccess.app/Contents/MacOS/ProtectOnAccess
ProtectOnAccess.app/Contents/Resources
ProtectOnAccess.app/Contents/Resources/Info.plist
ProtectOnAccess.app/Contents/embedded.provisionprofile
ProtectOnAccess.app/Contents/Info.plist
ProtectOnAccess.app/Contents/PkgInfo

I removed these folders:

ProtectOnAccess.app//Contents/_CodeSignature/CodeDirectory
ProtectOnAccess.app//Contents/_CodeSignature/CodeRequirements-1
ProtectOnAccess.app//Contents/_CodeSignature/CodeSignature
ProtectOnAccess.app//Contents/_CodeSignature/CodeRequirements

Next thing I had to do was change my executable name from protect_am to ProtectOnAccess in order to match what was in the CFBundleExecutable property in Info.plist.

Finally, when copying my code to the Application Support folder, I needed to remove what was there previously and then copy in the new application. This assigns a new inode to the files, which avoids a bug where the cached kernel copy of the executable is not refreshed.

Thanks, Quinn!

0