Core of macos itself is immutable and won't let you even add kernel modules or enable/disable system services, and IIRC it lives on a separate partition that is R/O.
I'm surprised they're advertising immutability on here.
One of the issues many commenters on hacker news have with MacOS is SIP which is exactly this. "If random binaries on my system can't overwrite kernel modules on disk, it's oppression!"
Something with privilege could usually just remove the immutable flag and then go on and do whatever dumb stuff it wants to do... But they usually don't.
My corporate macbook was at its most stable when I had set /etc/hosts immutable and the corporate chef got stuck and nobody yelled at me. Of course, a couple months later I did a mac os update and some corporate spyware interfered with the gpu driver... would have been updated if chef had run in the past three weeks. Whoops.
Yes, you can. You can also recompile the kernel with new options, or do whatever else. This has been misstated repeatedly in this thread, but macOS simply is not backed by a trusted hardware chain, end of story. It's not iOS. With SIP Apple has effectively implemented something like a more granular system immutable flag with kern.securelevel set to 1 like it was back until 10.3 or so (can't remember exactly when they changed it to 0), but just as you could drop down to single user mode back then SIP can also be disabled or modified at will. Having the restricted flag set on a bunch of core system .app bundles under macOS and a sane default policy is simply not the same thing as "you can't get rid of it". And I do think Apple should be legally required to provide decent built-in support for an owner controlled trust chain, but I don't think mixing up "you need to really know and be sure of what you're doing" with "it's hard prevented outside of bugs" is helpful.
macOS does not permit kernel extensions, because contrary to GNU/Linux they take ABI and kernel stability seriously, and are incrementally turning the OS into a proper microkernel, with all extensions running in userspace.
Yeah this kind of thing got me to leave the Mac platform. I don't mind security but I want to retain the final control and an all-or-nothing setting like SIP doesn't suffice.
I'm glad I'm off Mac but I will avoid any immutable OS now, seeing what that leads to.
It’s my understanding (and I imagine yours is better than mine) that at least at present, the macOS kernel is open source, which would mean that unless they forked it, disabling firmware security and SIP would mean that you could replace it with a compatible one compiled from open sources that skips such a check.
They can, of course, remove that option a number of ways: closed source kernel, disable the disablement of boot security (such as on iOS), et c.
The Mac remains the Mac. That is not changing. That has been repeated by Apple executives publicly many times. Part of the Mac's heritage is that you can turn off the guard rails and take control of your system, including installing things like kernel extensions. These are not things most users should need to do - secure by default is very important - but they remain possible.
Others have documented the engineering that went into a new boot system for the M1 to make multi-boot and custom kernels possible. Engineering that would be pointless if no one were expected to use it.
IIRC from one of the early posts that Marcan posted a couple of years ago, it's essentially impossible to completely get rid of MacOS due to the way the Apple Silicon boot process works.
I was not talking about macOS allowing it technically. I was pointing out the cultural differences between macOS and Linux. A homebrew like system that changes permissions of system directories will never fly in Linux land.
If you use an operating system like macOS, don't be surprised that it prevents you from having the freedom to do anything with your hardware. You live in a prison.
An important thing to recognize is that every version of macOS (and iOS!) so far has retained some official way to boot a custom/unsigned/"unclean" kernel, specifically for kernel (or kernel extension) development.
When SIP (rootless v1) was introduced, macOS came with a way to disable it, for the sake of kernel developers. When APFS was introduced by default, macOS retained two workarounds for kernel developers: both the ability to boot from alternate APFS volumes within the APFS container; and also the ability to install to/boot from HFS+. And when the system volume became truly read-only in Catalina (rootless v2)—that's right, even that restriction could be overridden via csrutil, specifically to facilitate kernel development.
Apple is never going to lock themselves out of booting custom OSes that are almost, but not quite, macOS; because that's how new macOS gets made.
And, of course, as long as you can boot something that's not literally macOS; then that same mechanism can always be abused to boot something that is much less macOS, or in fact not macOS at all (but may still seem to be macOS, from the bootloader's perspective.)
The Mac is the Mac. Apple Silicon doesn’t change that. You can set boot args, disable security, and other things the Mac has historically supported. In fact these things are required to develop 3rd-party kernel extensions which are still supported on Apple Silicon.
Due to the signed system volume, doing so is now impossible without disabling system integrity protection, one of the main platform security features of macOS.
I made an effort to do this for Mojave, but macOS is not designed to be modular, and after a week of chasing weird bugs related to interdependencies of system services, I stopped my efforts. If you'd like to collaborate, reach out.
reply