Is it safe to use SecTranslocateCreateOriginalPathForURL?

Question

Created Apr ’23

Replies 3

Boosts 1

Participants 2

I'm trying to keep track of some file information via Endpoint Security APIs. When I exec a file which is quarantined, the file is translocated to a different directory and the translocated path is what Endpoint Security shows (which makes sense because that's the path that's being executed).

If that file is blocked due to XProtect, I get a message from XProtect via Endpoint Security saying that malware was detected and a path to the offending bundle. Unfortunately, the path is to the original bundle--not the translocated one--making it difficult to reconcile with the data collected above.

I discovered a handy function, SecTranslocateCreateOriginalPathForURL, in Security frameworks which, given the translocated URL, will return the original URL. Works great. But there's no header for it.

Is this safe to use, or do I have to do some other odd things to get the two to reconcile?

Answer 1

DTS Engineer OP

Apple

Apr ’23

Is this safe to use … ?

No. For something to be a public API it must appear in a system header.

The lack of an API for this is something I call out in App Translocation Notes:

There is no supported way to determine the original (untranslocated) path of your app. Again, you’ll find lots of unsupported techniques for this out there on the ’net. Use them at your peril!

And to illustrate that last point, check out this post.

For most folks who ask this question the above is the end of the conversation. However, I think your case is worthy of further consideration.

Over the years many folks have filed enhancement requests for an app translocation API. The fact that this hasn’t happened suggests that our security folks specifically don’t want to support this. I’ve never seen an explanation as to why, but it’s not hard to think of potential reasons (I’m not going to speculate here because my management gets grumpy when I speculate).

Your situation, however, is not something I’ve seen before. It’s easy to see how app translocation might cause grief for ES developers using the ES_EVENT_TYPE_NOTIFY_XP_MALWARE_xxx API. I think you should file an ES-specific bug explaining how this impacts your product. I think it’s unlikely that we’d fix this by publishing a general app translocation API, but we could improve things by, perhaps, enhancing the es_event_xp_malware_xxx_t structures.

Please post your bug number, just for the record.

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

Answer 2

pmerchant OP

Apr ’23

Makes sense. I'm weak importing it ATM because it might go away. That said, the functions are actually documented at Apple's open source site. And if they're linkable in the Security Framework, I assume they're used by someone at Apple, so I don't know that the API may be changing too much...

Famous last words, I know... 😄

I submitted a Suggestion at FB12142638.

Answer 3

DTS Engineer OP

Apple

Apr ’23

That said, the functions are actually documented at Apple's open source site.

No they are not. That’s exactly what I was trying to explain in that post that I referenced. So, once more with emphasis…

Stuff you find in Darwin is not considered API. Darwin is a cool resource to understand how the system works but everything you find there is considered an implementation detail. If you encode implementation details in your product it may break on future system and there may be no way to fix it. I regularly talk with folks in exactly that situation and that conversation is never a happy one )-:

I'm weak importing it ATM because it might go away.

This won’t necessarily help. We could, for example, add an entitlement check that restricts this to Apple code.

I assume they're used by someone at Apple

Yes. That’s their intended audience. However, that won’t necessarily protect you. We regularly replace such routines because we know who is using them and can change all the callsites.

I submitted … FB12142638

Thanks.

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