| |
| ▲ | brigade 6 hours ago | parent | next [-] | | Which system integrity protection are you worried about missing? Muse being able to exfiltrate the contents of your messages db doesn’t compromise system integrity to begin with. It being able to write arguably does, but this whole conversation was about how to grant it full disk access in the future anyway. And OP had SIP enabled, but his system still got compromised with a remote exploit. | | |
| ▲ | throw0101a 5 hours ago | parent | next [-] | | AIUI, SIP protects "/" but not "/Users" (macOS' $HOME base). All your private data is in $HOME, so that's why Muse could get it even with SIP. | | |
| ▲ | brigade 5 hours ago | parent | next [-] | | Sort of; SIP originally was simply meant to protect /System from root. But nowadays, it's more used for system attestation. Which in turn is used by the OS to decide how to ask for and enforce certain user permissions and sandbox profiles. | |
| ▲ | lapcat 4 hours ago | parent | prev [-] | | > SIP protects "/" but not "/Users" (macOS' $HOME base). > that's why Muse could get it even with SIP. Both of these assumptions are mistaken. |
| |
| ▲ | lapcat 5 hours ago | parent | prev [-] | | > Muse being able to exfiltrate the contents of your messages db doesn’t compromise system integrity to begin with. I care more about the integrity of my personal privacy than I do about the integrity of the "system". The point of the system is to serve me. > And OP had SIP enabled, but his system still got compromised with a remote exploit. Nobody said that SIP magically prevents macOS bugs and security vulnerabilities. | | |
| ▲ | brigade 4 hours ago | parent [-] | | Protection from the sort of malware OP was hit with is the most commonly cited dire warning against disabling SIP. I just assumed that was also the reason you were against disabling SIP in order to grant permissions to software you intentionally installed. | | |
| ▲ | lapcat 4 hours ago | parent [-] | | > Protection from the sort of malware OP was hit with is the most commonly cited dire warning against disabling SIP. I just assumed that was also the reason you were against disabling SIP in order to grant permissions to software you intentionally installed. No. The confusion here is that the Stratechery post combines multiple stories. There was a macOS screen sharing vulnerability, now fixed. The vulnerability existed even with SIP enabled, and that vulnerability is how Ben Thompson's Mac was hacked. The question was, why did Thompson's Mac have the screen sharing port open to the internet, and that's when Thompson explained that the Mac was running an agent. Coincidentally, Apple published a developer note on Friday about upcoming changes to Full Disk Access, which mentioned AI agents. Apple did not give any specific reason for this change, but presumably the inspiration was a very recent public controversy initiated by a journalist whose Messages database on macOS was read and uploaded by the Meta Muse app. Muse and similar AI apps request Full Disk Access to access all of the user's information. Without SIP, these apps would be able to suck up all of your data without permission. | | |
| ▲ | brigade 3 hours ago | parent [-] | | If you're arguing that SIP isn't a useful defense against malware, I agree there. Sandboxing full disk reads is orthogonal to what SIP actually provides. It's entirely possible for an unsandboxed binary to slurp your private data even with SIP enabled. | | |
| ▲ | lapcat 3 hours ago | parent [-] | | > If you're arguing that SIP isn't a useful defense against malware No? I'm not. SIP is of course not a universal defense against every possible kind of attack, but did anyone ever expect it to be? > Sandboxing full disk reads is orthogonal to what SIP actually provides. No, because again, as I already said, disabling SIP also disables some TCC privacy protections. > It's entirely possible for an unsandboxed binary to slurp your private data even with SIP enabled. Not the data protected by TCC. | | |
|
|
|
|
| |
| ▲ | 6 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | john_alan 4 hours ago | parent | prev [-] | | What about all the stuff they've done to keep it open: - Per-install boot security policies - Custom kernel boot (kmutil configure-boot) - Raw-image boot mode - XNU source releases - Disabling SIP - Disabling the Signed System Volume - Third-party kernel extensions - Developer ID distribution and notarisation - Gatekeeper "Open Anyway" override - Hypervisor.framework - Virtualization.framework - Rosetta for Linux VMs - Nested virtualisation - macOS guest provisioning - DiskImageKit - Custom Virtio devices - Containerization framework | | |
| ▲ | lapcat 4 hours ago | parent [-] | | > What about all the stuff they've done to keep it open I don't understand the purpose of your reply? One of your examples is "Disabling SIP", but you're replying to a thread that has already been discussing this very topic, so it makes no sense to ask us "what about" that. > - Third-party kernel extensions Deprecated: https://developer.apple.com/support/kernel-extensions/ The issue is really the difficulty of using macOS as an expert user, and this has become significantly more difficult over the years. You mention "Developer ID distribution and notarisation", but both of those are actually restrictions that were added later to a previously open system. Notarization in particular has become a major pain for developers. Also "Gatekeeper Open Anyway override" has become significantly more difficult for users over the years. | | |
| ▲ | john_alan 4 hours ago | parent [-] | | > I don't understand the purpose of your reply? to illustrate, counter to the HN narrative, they've actually done a lot to keep the platform open to hackers and hobbyists. Sure, remove disabling SIP from the list, the others still stand and are quite compelling IMO. Fair enough on the kernel extensions. I take your point(s) but the doom about the Mac turning into iOS and the terminal being taken away is unfounded. | | |
| ▲ | lapcat 4 hours ago | parent [-] | | > to illustrate, counter to the HN narrative, they've actually done a lot to keep the platform open to hackers and hobbyists. My comment that you replied to was not about the HN narrative. Thus, I still don't understand the purpose of your reply. |
|
|
|
|
