4 ms·
> 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 Launch
by sgjohnson 9mo 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/15f995a4e849acd75caf14f2e50e7e98 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.
- AceJohnny2 9mo ago> 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/ https://eclecticlight.co/free-software-menu/
- sgjohnson 9mo agoThat 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.
- AceJohnny2 9mo agoDisabling 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.
- jabwd 9mo agoThe thing I find disappointing about the article is that nothing else seems to have been explored. Now no options might exist, but then again, isn't the point of such a write up to find the ones that.... do...? A lot of people know that modern macOS is a bit of a let down when it comes to modifying it unless you disable a bunch of security layers. So the information gained is basically 0. Edit: I should clarify that some of the ways they analyze how services are launched etc. are quite interesting, though I hope my prior thought makes sense to some.
- philistine 9mo agoDisabling the SSV is perhaps the worst mistake you can make to a macOS install. Howard certainly knows that this is true but has chosen not to explore the details in this article. His website are deep dives into the technical workings of macOS that no one else does. I’d even argue he has more insights and documentation than Apple. It might sound harsh, but he’s just very clinical about it.
- sbuk 9mo agoIt 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.
- Moto7451 9mo agoI 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-certified/ 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.
- sgjohnson 9mo agoFunnily enough, they had no certification and weren’t compliant in 10.0-10.3 days, so what they were doing was trademark infringement, hence the lawsuit from the Open Group. 10.4 was the first compliant version. And oh boy they really milked it for several years afterwards. https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified/answer/Terry-Lambert https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
- catoc 9mo agoEclecticlight 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
- sgjohnson 9mo agoI 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).
- catoc 9mo ago> 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)
- sneak 9mo agoDisabling SSV puts your system security on par with any stock linux distro. Most OSes don’t do a cryptographically verified read only root.
- sgjohnson 9mo agoThe 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.
- zbentley 9mo agoI 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."
- pjmlp 9mo agoIf 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-usenix-atc 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.co/conversations/rZXhqtP/that-time-i-had-steve-jobs-keynote-at-unix-expo https://web.archive.org/web/20180628214613/https://www.cake.... "NeXT marketing strategy video (1991)" https://www.youtube.com/watch?v=KRBIH0CA7ZU https://www.youtube.com/watch?v=KRBIH0CA7ZU
- userbinator 9mo agoDoes it really matter? Almost certainly no. ...until they start including things you don't want (remember the CSAM scanning debacle?)
- lapcat 9mo agoThe 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.
- DrBurrito 9mo agothis. 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
- wepaean 9mo ago[dead]
- eviks 9mo ago> 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?
- sgjohnson 9mo agoBroken 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.
- eviks 9mo agoWhat 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?
- sgjohnson 9mo ago> What is subjective about objectively saving time in your workflow? What part of your workflow requires modifying the system volume on macOS? As a long-time power user of macOS, I don't even need to disable SIP. I've worked my workflow around the limitations. macOS and Linux power users are two different species. One will work around the restrictions imposed by the overlords, the other will beat the system into submission. Of course you can also beat macOS into submission, but then you're in for a bad time.
- eviks 9mo ago