Post not yet marked as solved
Thanks Quinn for this very clear confirmation.
I’m not sure why you want to defer that work to an XPC service but it’s not in line with our expectations
The problem I try to solve is the same as the original subject of the thread ‘Deny uninstalling SysExt’. In particular when disabled from System Preferences.
Post not yet marked as solved
In my case it’s about managed Macs.
Post not yet marked as solved
About using an Agent as Extension Manager Delegate.
I tried using an Agent (XPC Service) hosted in the System Extension’s host app.
Then I have something like:
Container.app
/Contents/Resources
/Contents/Library/SystemExtensions/Extension.sysext
/Contents/XPCServices/Agent.xpc
The agent cannot load the system extension (error ‘extension not found’).
This seems coherent with documentation stating that extensions are searched at /Contents/Library/SystemExtensions from main bundle. XPC Service’s main bundle is the Agent.xpc above.
However I noticed that the OSSystemExtensionRequest has a nil attribute named _containingApplication this looks like container app support is somehow planned.
Also there’s an error OSSystemExtensionErrorUnsupportedParentBundleLocation in the Framework which hint again at nested bundle support.
Did I missed something. Is there a way to say to SystemExtension Manager that it need to look at the XPC’s container app bundle instead of own bundle ?
Post not yet marked as solved
Yes it is likely that root was used to mean admin.
Standard users cannot disable SysExt so there’s no issue for them. MDM configuration profiles (user-accepted or DEP) can whitelist the SysExt but cannot prevent unloading.
Maybe this is related to the complexity of integrating with Finder or other dynamic unloading/reloading of SysExt.
Anyway MDM policy could be a way to deal with it.
SysExt delegate maybe also (to be seen which process would have to host the delegate).
But my surprise is mainly that I should be able to deny moving app2 to trash if my SysExt is hosted in app1. This has worked for some time but fails as of 12.5. I filled a feedback FB10168135.
Regards,
Jerome
Post not yet marked as solved
Sorry my ascii art is broken for bundle hierarchy.
Post not yet marked as solved
Hi,
I face the same issue.
I noticed stance behaviors :
Terminal commands such as rm and mv are managed when rename or unlink/truncate events are denied.
Finder usage (as described in your post) used to work for some time (Finder always trigger rename events) but is failing since 12.4 (and 12.5 betas)
There’s no event for disabling the extension from System Preferences (kext event do not apply)
If somebody has some hint here it is welcome.
Regards,
Jerome
Post not yet marked as solved
Hi sourabMIC,
Looking at your rules you allow all outgoing traffic to port 80 & 443. Please note however that some captive portals might use 8443 or any other port - there are plenty of implementation variants.
I'm not sure if you want to avoid some traffic but please note that macOS Captive Portal Assistant usually kicks in using captive.apple.com host check. This might help you adjusting the NENetworkRule at least temporarily to allow other ports.
Sorry for the typo I meant NSWorkspace.runningApplications.
Post not yet marked as solved
Hi,
An update: as I use KVO on NSWorkspace main run loop remains mandatory (documented and tested).
Anyway I’m not sure if the difference is only footprint-relative or if there are more complex reason for going GCD only.
Waiting for NEHotspotHelper on Mac, I've been able to implement a (somehow) working solution relying on NSRunningApplication.runningApplications.
When looking at CNMarkPortalOnline documentation:
Captive Network Support will notify the rest of the system that WiFi is now a viable interface.
How does this notification occurs ?
Is there an event or notification such as 'Captive Portal is now Online' ?
Hi an update on this topic.
Using SNI using handleOutboundDataFromFlow fails because near all traffic is encrypted and no headers or metadata can be fetched for that purpose.
I tried as B-plan to replicate capture.apple.com behaviour to detect redirects and allow them. This is a tricky job because the Firewall rules need to be updated live to follow redirects but on the paper (i.e simulating with Safari) it works.
However in captive-portal tests I face another problem: Captive Portal Assistant seems to block all traffic out if his own session (not sure how this is done). For Example Safari or curl won't get a response while the CPA is opened, as they do under the same SSID if CPA is closed.
Is some way this could be an helpful solution for my use-case if I was able to confirm that CPA session is ongoing.
CNCopySupportedInterfaces seems to be dedicated to that and is available on Mac.
However it always returns null. I know that some (obsolete) CN API require some specific entitlements on iOS but I've found nothing about Mac requirements.
Any hint ?
If my understanding is good you suggest :
Using RFC7710 to grab captive URL
Get SNI during handshake and compare with portal host
Drop handshake flow if they don’t match
This limit to a subset of portals implementing the RFC but could be a good start. I’ll try that.
Hi Matt,
Thank you for looking at this topic.
My concern is not for a specific portal I can whitelist explicitly. I’m looking to support any portal (hotels, transportation, restaurants, etc).
Regards,
Jerome Tarantino
Post not yet marked as solved
Feature request is sent as FB9963670
