Well that's a nice, simple answer for that, at least. 😄

Well it's not an ES sysex yet because I'm still waiting for Apple to give it to me. It's been 5 or 6 weeks, although I recognize the holidays mess everyone's schedules up. Is it possible to customize an ES sysex launchd file? This is for future reference, I'm not sure that I do need any such customization -- my initial thought had simply been to have a simple launchd.plist that said "run this all the time" and install that via the pkg installer. I'm rewriting my containing app's extension loader code right now, to handle multiple extensions.

Fortunately, I am familiar with the differences between an agent and a daemon. 😄 I am very relieved to know I wasn't reading things incorrectly about SMBlessJob. The basics of what I was trying to achieve: we'll have a daemon, which will be used to do things like start and stop the proxy as needed, coordinate information about the system account and related settings, check for updates (if we don't end up using App Store deployment, which seems likely to be the case), and various other things. It'll need entitlements because -- once I get the bit from Apple -- I'll also have it doing anti-tampering using Endpoint Security. All of that is pretty simple and basic. What I had hoped to do, however, was allow a drag&drop installation. In that case, when the container application was launched, it would check to see if various files were installed, and if not, do that itself. But to do that it would need user permission, and the call I would have used has been deprecated. I think I can do that using a helper-tool with privilege, but I haven't mapped that out yet (for clarification: the "think I can do that" means that, yes, I am fairly positive it's technically possible, but I haven't figured out what the details are or what the code would look like). Instead, at least for now, I think we'll have to rely on a pkg installation method, which can run a script to install a plist in /Library/LaunchDaemons as well as a few other things. The preferred installation mechanism will presumably be via MDM. Which means that's going to be one of the next things I have to ask about, but that's for another time. 😄 I hadn't at all thought about having it claim it's a system extension. But since I want that tasty Endpoint Security capability... that might work, mightn't it? In which case, the daemon would be part of the app bundle, and then get it installed using OSSystemExtensionRequest. (If you could see my face right now, you'd see my eyes wide and looking up to my left...)

No, that's right, I need to use the app-like structure because of entitlements. So given that, I don't think I can use SMJobBless?

My question is complicated by me (currently anyway) having the daemon as an app bundle, embedded inside my wrapping app so it has its own set of resources. But I can deal with that by simply asking for the bundle for the main app by its bundle ID, I presume, and having something like MyApp.app/Contents/Library/Daemon/Resources. I had gone for the app-like approach because of a post Eskimo wrote, that I can't find right now but I probably have stashed in my copious and disorganized notes.

Check that this helper app or daemon is placed in the correct location inside the bundle as described here. That link doesn't mention daemons, though. If an app has something that is intended to run at boot time, I had assumed a launchd plist would be installed by the app into /Library/LaunchDaemons -- is /Applications/AppName.app/Contents/Library/LaunchDaemons intended instead?

Ah ha! MDQuery, searching for kMDItemDisplayName and/or _kMDItemDisplayNameWithExtensions should do the trick. I haven't written the code for it yet, but that should do the trick.

And, ok, I got that solved.         let exportedInterface = NSXPCInterface(with: MyProtocol.self)         let allowedClasses = exportedInterface.classes(for: #selector(setList(_:withReply:)), argumentIndex:0, ofReply:false)         let newSet = allowedClasses.union(NSSet(object: MyClass.self) as! Set<AnyHashable>)         exportedInterface.setClasses(newSet, for:#selector(setList(_:withReply:)), argumentIndex:0, ofReply:false)         newConnection.exportedInterface = exportedInterface (I have to do the same in ObjC for the "user" side, because it can get a list of MyClass in a reply, but ObjC is a lot easier, and better documented as well, for this.) Thanks 😄

I am in fact failing to find examples of setClasses(_:for:argumentIndex:ofReply:) for Swift. The big thing I'm running into is that the .class member of a class is not hashable. Specifically: note: only concrete types such as structs, enums and classes can conform to protocols

That gets done in the part that will receive the data? And if I call that, I have to also specify String/NSString, Int/NSInt, etc., in addition to my custom classes? I will be googling for examples later, since I have just woken up, but thanks as usual. 😄

So, given that, how -- and I realize this is a really broad question -- do you determine if an app's signature is, uh, legitimate? I've stared at that for several minutes now; I know there's a big step I'm not taking to frame it correctly, and I think that would also answer it. 😄 Pardon me while I break down my thoughts a bit. A signature would be "uh, legitimate" if it is either signed by Apple, or signed by the team that said it did. (I mean, I assume I can't create a team called "com.apple.sean" or, I suppose more importantly, can't claim to be com.google and have an app called "Google Chrome" with a bundle identifier of, say, "com.kithrup.hahahaha.fooled.you" but a signing identifier of "com.google.chrome". It is an assumption.) I can throw this in its own post and expand on my uncertain thoughts if that would be better.

(I realize I could look in /Applications and /System/Applications, but on macOS an app can be in other locations and still be usable. And, I'd also kinda like to know what happens if there are multiple matches for it on the system. This seems like the kind of thing Launch Services would handle, but a medium-length check didn't show anything.)

You can use the audit token as a cache key to avoid taking these slow paths every time. Yeah, my experimental setup uses multiple processes (why? Because I am experimenting in it 😄), so one thing I was thinking of trying would be used for a block/allow list, and have the C&C process say "This app/executable is going to be treated differently somehow," and then send that down to the provider, to use for cache checking. (Rather than doing it in the provider, which I already think takes way too long, which is why I am also playing around with Instruments.) But it looks like I can't safely/reliably do that.

Because NEFlowMetaData originated on iOS where the code signing identifier can be trusted. Ok that actually occurred to me last night as I was unable to sleep. 😄 The NE flow metadata also has the sourceAppUniqueIdentifier -- I assume there's a way to go from a filesystem path to that? One of your posts mentions a cdhash which I presumed was the same thing, but I didn't see how to get either one. Thanks!

Also... if the code signing identifier can't be trusted, why is that what the OS gives network extensions? (I guess it also gives the audit token, but that's opaque and I'm still not clear on what is and is not supposed to be obtainable from it. :))