deleting stock apps on os x programmatically - macos

Does anyone know if there’s a way to delete stock apps on 10.11 programmatically without disabling SIP and rebooting the machine? Or, is there a way to disable SIP without rebooting? Thanks!

If you have a kernel signing certificate, you can disable SIP without rebooting with Rootfool. You'll need to compile it yourself.
Rootfool tool uses a kernel extension, which will only be loaded by the kernel if it's signed, or if SIP is turned off.
Without the signing certificate, no, you can't delete any of Apple's system files with SIP turned on. SIP is there to protect from the operating system being corrupt by malware, or accidental deletion and Apple has included its own applications as being protected by SIP.

Related

Loading KEXT without rebooting on Big Sur

According to Apple it is necessary to reboot macOS when loading (or updating the KEXT). I have already disabled SIP. However, it is still cumbersome to do a reboot, especially for development. I know that KEXTs are deprecated and that the KEXT cache has to be rebuilt. However, is there some (undocumented) possibility to load/update the KEXT without having to reboot?
I did some research and tried some boot-args options without success.
No, from Big Sur onwards, all loadable kexts are linked into a single pre-linked kernel image, and it's not possible to mark kernel pages as executable after a certain stage has been reached during boot.
Attempting to load a kext which is not in that image adds it to the list to be included in the prelinked image. The reboot then causes the new pre-linked kernel to be loaded.
Yes, it's annoying, but no, there's no workaround, other than using 10.15/Catalina for debugging/testing when you're not specifically dealing with 11.0/Big Sur issues.

Is there a way to add the Network Extensions capability to a macOS app without joining the Apple Developer Program?

I want to build a macOS app that filters specific network requests so I need to add the NetworkExtensions capability. But after I add a NetworkExtensions capability, I get the following message:
Your development team, "Potato Dev2", does not support the Network Extensions capability.
Image of where the above message is from: https://i.stack.imgur.com/H46gE.png
From Apple's documentation on "Adding Capabilities to Your App":
The platform, and whether you're a member of the Apple Developer Program, may limit the capabilities available to your app
The documentation doesn't explicitly say which capabilities require being a part of the Apple Developer Program. I also don't see why I'd need to be a part of the Apple Developer Program to write software on and for my own computer. Note that, at least to my knowledge, the NetworkExtensions capability does not depend on any service from Apple (as opposed to HealthKit or Game Center).
So is there a way to add a Network Extensions capability to a macOS app without joining the Apple Developer Program?
You should be able to do it if you disable system integrity protection (SIP) on your Mac (csrutil disable in the Terminal in the macOS Recovery Environment), and disable amfid's entitlements check by adding amfi_get_out_of_my_way=1 to the kernel's command line arguments. (Again in the recovery environment, nvram boot-args='amfi_get_out_of_my_way=1')
You will need to bypass Xcode when code signing and use the codesign command directly because Xcode performs the provisioning profile entitlements check, as you noticed. codesign itself does not perform this check.
This works for basically allowing just about anything to do with DriverKit system extensions, so I'd expect it to work with Network System Extensions as well.
I figured out the answer to my question: to write macOS software that uses the NetworkExtension APIs, you must be a member of the Apple Developer Program ($100/year). See https://developer.apple.com/support/app-capabilities/ for details.

Whitelisting an unsigned kext in macOS Catalina

I've recently bought an old Alesis io26 Firewire Audio interface. The last driver release was only working on mountain Lion and older. After some time I've managed to install said drivers on Catalina, by manually dragging the midi driver into /Library/Audio/MIDI drivers and installing the kernel extension into /System/Library/Extensions via KEXT droplet. The problem I have now is that my mbpro only recognises the Interface if my SIP is disabled. I've heard that the driver is not signed and that this is the reason why the SIP is preventing it from working. So as a total noob, how can I somehow whitelist that kext so that I don't have to go to recovery mode and disable SIP every time I want to record some Audio.
The 3 "correct" ways of doing this are probably unlikely:
Get the original developer to sign the kext
Somehow persuade Apple to add it to macOS's built-in whitelist
If you have a kext signing certificate yourself, you can sign it. (Apparently, Apple no longer issues these, however.)
The best you can do in practice is probably to only disable the kext signing part of SIP by using the command
csrutil enable --without kext
instead of
csrutil disable
Of course, this leaves your system open to being attacked via unsigned kexts, though I've not heard of any malware that specifically targets Macs with kext signing disabled.
Actually, the question is for Catalina. We cannot partially disable SIP by running with --without kext. from Mojave this option is disabled and one has to either enable or disable it from Recovery OS.

How to run un-signed System Extensions in OSX catalina?

How to run un-signed System Extensions in OSX catalina?
I'm trying to load SimpleFirewall which is a system extension given by apple, ment to demonstrate packet filtering capabilities.
The project compiles, but I get this error during run:
OSSystemExtensionErrorDomain error 8
Looked it up, it means -
Invalid code signature or missing entitlements
I have SIP disabled, and turned off code signing in the xcode project.. what else can I do to have this run? I dont have a developer ID.. just testing the code..
As per Eskimo answer on Apple Developer Forums you might additionally to
disabling SIP and
enabling SYSX developer mode (systemextensionsctl developer on)
need to disable AMFI:
nvram boot-args="amfi_get_out_of_my_way=0x1”
This has to be done in the cmd from the Recovery Mode.
AFAIK you only need to do it, if you don't have a developer provisioning profile with com.apple.developer.endpoint-security.client entitlement.
Apple's Documentation on 'Debugging and Testing System Extensions' has some information on this subject.
In theory, disabling SIP should take care of the signing requirements. You may still need to sign the extension with a free Mac Developer certificate so that the entitlements can be embedded.
Are you trying to use the extension from outside an app? If so, the command
systemextensionsctl developer on
Should help.
I have a same issue with #tuti.
I am testing a hello world System Extension base on Driver Kit. I am using free developer account, Mac mini Catatila, Xcode 11 to development.
In my Xcode, I setting to don't sign my code for both application and system extension. I am also disable SIP and run command "systemextensionsctl developer on".
But when I load my system extension from Swift application, it still show me the log "The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 8.)". When I look up the error 8, it means invalid signature. But in my computer, I can load an unsigned Kernel extension normally.
So, I don't know why? I think the OS still check code signing for system extension regardless I disable SIP.

Mac OS High Sierra kext signing

Apple recently introduced a new security feature in Mac OS High Sierra for 'User Approved Kernel Extension Loading'.
"...a new feature that requires user approval before loading newly-installed third-party kernel extensions (KEXTs). When a request is made to load a KEXT that the user has not yet approved, the load request is denied. Apps or installers that treat a KEXT load failure as a hard error will need to be changed to handle this new case."
Does this mean developers can sign kexts with their own developer certificates, and no longer need specific Apple approved certificates to ship kexts to users?
Heard back from Apple that this does not change the kext code signing process, you still need certificates from them to sign your kext.
https://developer.apple.com/library/content/technotes/tn2459/_index.html
Secure Kernel Extension Loading is a new security feature of macOS High Sierra. macOS now requires you to manually approve the installation of third party kernel extensions. Everything remains the same at developer side to sign kext with apple approved certificate.

Resources