What is "launchservicesd CHECKIN:0x0-0x85085 3340 com.domain.App" ?

Dear Apple team,


I am developing an agent and a daemon on MacOS 10.13.6. They are placed inside App.app which is signed. After the installation of my product, I noted the logs in the console:

"

Application Stub AppleEvents: received mach msg which wasn't complex type as expected in getMemoryReference.

Application Stub OSErr AERemoveEventHandler(AEEventClass, AEEventID, AEEventHandlerUPP, Boolean)(spec,phac handler=0x7fff505a1a98 isSys=YES) err=0/noErr

launchservicesd CHECKIN:0x0-0x80080 3291 com.domain.App

amfid /Applications/App.app/Contents/Resources/agent signature not valid: -67050

amfid /Applications/App.app/Contents/Resources/daemon signature not valid: -67050

agent start: 1557471773 66344

launchservicesd CHECKIN:0x0-0x85085 3340 com.domain.App

daemon start: 1557471775 13374

agent LSExceptions shared instance invalidated for timeout.

App LSExceptions shared instance invalidated for timeout.

agent AppleEvents: received mach msg which wasn't complex type as expected in getMemoryReference.

agent AppleEvents: received mach msg which wasn't complex type as expected in getMemoryReference.

...

"


I signed App.app and installation package App.pkg, but the agent and the daemon are not (do not know how to do it).


Could you please explain logs. Should I worry about "CHECKIN" and "signature not valid" logs? Will my software be started on the latest version of MacOS?


Regards,

Valery.

Up vote post of ValeryK Down vote post of ValeryK
2.8k views
Posted by
ValeryK
Reply
Add a Comment

Replies

I fixed "signature not valid" by moving the agent and the daemon to .app/Contents/MacOS

Posted by
ValeryK
Up vote reply of ValeryK Down vote reply of ValeryK
Add a Comment

I fixed 

signature not valid
by moving the agent and the daemon to 
.app/Contents/MacOS/

Right. That helps because it causes your agent and daemon to be signed as code. When you have these components in 

Contents/Resources/
they are signed as data belonging to the parent app, and that never ends well.

See the Nested Code section of Technote 2206 macOS Code Signing In Depth for more information about how to correctly sign nested code.

Despite the above, what you’re doing here is not acceptable. It’s not safe to create a launchd daemon that points directly into 

/Applications/App.app/Contents/MacOS/daemon
because that represents a privileged escalation vulnerability. Specifically, any admin user can move 
App.app
out of the way, replace it with a different app of the same name, and thus escalate to root without authorisation.

A similar problem affects your agent, in that moving the app out of the way lets one admin user run code as another admin user without authorisation.

You must copy these components to a privileged location before installing them. If your app has an installer, you should set this up in your installer. If your app installs itself, you can use 

SMJobBless
to install your daemon and then use it to set up your agent [1].

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"

[1] By:

  1. Copying the agent to a privileged, temporary location

  2. Checking its code signature

  3. Moving it to its final privileged location

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment