Comment by sgjohnson
18 hours ago
> Here’s our first problem, as those are located in the Signed System Volume (SSV), so we can’t change them in any way. The same applies to the other 417 LaunchDaemons and 460 LaunchAgents that account for most of the processes listed by Activity Monitor. In the days before the SSV it was possible to edit their property lists to prevent them from being launched, but that isn’t possible any more when running modern macOS.
SSV can be disabled. It would be ill-advised to do so, but Apple intentionally allows you to do that. In fact you can strip away every single security layer of macOS, including allowing unsigned kernel extensions to be loaded. This document is a bit outdated, but it should still be possible to do all of that. https://gist.github.com/macshome/15f995a4e849acd75caf14f2e50...
Feels like the article is just a cheap dunk on macOS. Has Apple perhaps baked in a bit too much into the SSV? Definitely. Even the Chess.app is in there.
Does it really matter? Almost certainly no.
> Feels like the article is just a cheap dunk on macOS.
That blog, Howard Oakley at eclecticlight.co, is consistently the most informative on the internet about macOS behaviors and internals, that Apple does not explain. He is also the author of several useful tools [1] to help observe and understand some of its underlying details. It's maybe the closest we have to a SysInternals for macOS.
[1] https://eclecticlight.co/free-software-menu/
It is. Add we all have off days. Perhaps Howard has had one here. I mean, he is defining what type of OS it is by how it's configuted. Which is just wierd.
I got a chuckle out of that for my own reasons as a long time Mac user as “Mac OS X is Unix” was the brand back in the 10.0-10.3 days, to the point I believe they got a Unix certification by someone, and then again with macOS 15 they got an Open Group UNIX certification.
https://www.osnews.com/story/140868/macos-15-0-now-unix-03-c...
I can’t say this affects me in any way I’m aware of, but the perception presented here is interesting.
1 reply →
That just highlights my point about this article being a cheap dunk?
Because I was very disappointed with it ending at “SSV doesn’t let you”. SSV can be disabled, and the author should have known (almost certainly knows) that.
Disabling SSV may have been beyond the scope of the experiment the author was attempting. I suppose he could've been more explicit about that.
From one of his comments on his post:
> I wish whoever takes that project on, every success, even more so at working out how those processes can be disabled completely while keeping the SSV intact.
1 reply →
Eclecticlight and ‘cheap dunk’ ?
No.
This site is a class of its own, in quality of discussions, in quality of software, and in dedication… many years long, consistent quality
I didn’t claim that eclecticlight writes cheap dunk.
But this article, which starts with
> That’s a question I’m asked repeatedly, which this article tries to answer.
doesn’t actually _try_ to answer the question. It just stops at SSV and draws a meaningless comparision with macOS 9. It also has several factual inaccuracies in there. Notably, the claim that macOS is not UNIX, and the implication that Unix systems must somehow be free and open-source (virtually all Unixes of the day were proprietary & closed source).
> I didn’t claim that eclecticlight writes cheap dunk
Thanks - then we agree (also on the part of the argumentation about macOS being a certified UNIX OS)
I suspect that Oakley could have explained that, but the thesis stands even without the asterisk, and explaining it would have an issue:
This is going to piss off some Linux folks, but when communicating from a big pulpit about how to bypass parts of MacOS, it's important to be aware that the vast majority of MacOS users are casual, nontechnical users. As such, a popular blog posting "here's how to bypass SIP/SSV lock/whatever" would lead to a wave of users disabling it for less-than-great reasons (aesthetics, conviction that e.g. a given service was causing their system slowness when that service's resource usage was actually symptomatic of something else orchestrated by MacOS going wrong). Those decisions have side effects:
- Folks brick or break their computers, potentially in a way that voids the warranty or support contracts (I hope that software bypasses don't trigger this, but I am cynical).
- Folks chasing a "cleanliness vibe" leave a lot of the system security off once they're done. Someone else in this thread pointed out that without SSV the security of MacOS is on par with most Linux, but MacOS users are a lot bigger attack risk than Linux users: there are more of them, they're wealthier and thus identified as targets of choice by malware/people, and, again--they're casual users and don't have good security spider sense. This isn't a blanket endorsement of every restriction/security feature with no opt-out that MacOS has, just an observation that its userbase is at higher risk for attack than some others--lower than windows, but higher than Linux users.
- Folks induce breakage that bricks their computers on a delay, e.g. during the next system update something chokes after encountering a totally unauthorized/unexpected service geometry and crashes hard enough to cause data loss.
I'm not saying that stuff like SSV-rw should be secret, just that it's probably for the best to not discuss it front and center in a widely-read informational blog whose content is geared towards (power) users rather than technicians. To phrase it with a different example: if someone Googles "how to disable XProtect (antimalware)", great, go nuts. But it's probably for the best that a popular article about "can you reduce resource usage by shutting down system launchd services" doesn't have a "here's how to elevate your permissions and disable whatever you like" blurb, and instead settles for an answer of "no, that's not supported."
If you want to piss off even more, those that buy Apple only because they want a shinny UNIX, but don't buy into Apple's culture since Mac OS Classic days, you only need to remind them that Steve Jobs was hardly a UNIX fanboy.
Just like with Microsoft strategies, for NeXT, having NeXTSTEP being based on UNIX was more to check boxes against Sun, and bring software into the platform, not to make it easy to go out, hence the whole userspace stack, even drivers, are based on Objective-C frameworks.
"Why We Have to Make UNIX Invisible."
https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u...
> They said a Unix weenie was code for software engineers who hated what we were doing to Unix (the operating system we licensed)—putting a graphical user interface on it to dumb it down for grandmothers. They heckled Steve about his efforts to destroy it. His nightmare would be to speak to a crowd of them.
https://web.archive.org/web/20180628214613/https://www.cake....
"NeXT marketing strategy video (1991)"
https://www.youtube.com/watch?v=KRBIH0CA7ZU
You sure you're replying to the right post? I wasn't really engaging with the "is it UNIX or not" debates elsewhere in the parent threads; just talking about why security bypass wasn't mentioned in TFA.
1 reply →
> Has Apple perhaps baked in a bit too much into the SSV? Definitely. Even the Chess.app is in there. > Does it really matter? Almost certainly no.
Why does waste and broken customization not matter?
Broken customization is entirely subjective.
As for waste - for the past decade or so, the consumer computing world has been in an almost unanimous consensus that computing power is cheap, and that it's not worth optimizing away a few hundred megabytes of storage or RAM. And macOS is _nowhere_ near being the worst offender here. If you really need to point a finger at waste, look no further than Windows, where just about everything these days is a WebView. Now that's waste.
I'm pretty confident that the taskbar on Windows 11 alone eats up more RAM and CPU time than every single macOS service that's running but not actually being used combined.
What is subjective about objectively saving time in your workflow? Or saving space that you can save more of your precious photos?
Also why should I care about worst offenders, that's not a coherent argument when discussing this specific offender.
P.S. Also, in what kind of world subjective perspective doesn't matter for the subject?
2 replies →
The problem is that Oakley is actually wrong. You don't need to edit the property lists. You can simply use the launchctl command-line tool to disable system launchd services after you disable SIP, without having to disable the SSV.
this.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.backupd.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.backupd-auto.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.backupd-helper.plist
Does it really matter? Almost certainly no.
...until they start including things you don't want (remember the CSAM scanning debacle?)
Disabling SSV puts your system security on par with any stock linux distro. Most OSes don’t do a cryptographically verified read only root.
The bigger problem with disabling SSV and making changes to it is entirely practical - any macOS update will overwrite them.
Which can be worked around by writing a provisioning script, but in either case will be a significant headache if one would come to rely on the modifications they were to make to the volume.
[dead]