Yet another macOS privacy protections bypass • Hacker News Board

Re: Yet another macOS privacy protections bypass

#91

Post by Razengan » Wed, Dec 02, 2020, 11:23 AM UTC

cglong wrote: post #81

Razengan wrote: post #64

Earlier quoted context omitted.

> In a way, it surpasses democracy. Is there any form of democracy in practice that doesn't involve money? > The HN crowd in particular has a sizeable influence on other people with regards to technology. Because we are the techies, people ask us what they should use/buy. See, many of us do recommend people to buy Apple. Because they're still very much the lesser evil among the Microsofts and Googles. If Apple does g…

I haven't purchased an Apple product in three years but I'm still stuck using iCloud.

iCloud is still easier to move out of and never see again than say GitHub or YouTube, both of which were not owned by Microsoft or Google before but now here we are.

Re: Yet another macOS privacy protections bypass

#92

Post by Razengan » Wed, Dec 02, 2020, 11:48 AM UTC

mleonhard wrote: post #85

Razengan wrote: post #58

Earlier quoted context omitted.

Not related to Macs but coincidentally StarCraft was also the first time ever I "cracked" a game. ^^ For whatever reason, the copy protection was not recognizing my game disc (apparently only worked on Windows 95 but not 98 as I found later). This was my most anticipated game yet, so I made myself learn Windows/PC debugging on the spot — without the internet — which basically amounted to single-stepping through every…

Impressive! Broken video games motivate a lot of learning. When I was a teenager, we had three game-capable PCs, but only two had LAN cards. I also had an underpowered LAN-connected Linux machine. I connected the non-LAN PC to the Linux box with a parallel cable. Linux could route packets between the LAN and parallel-cable network. But DOS games find each other with local broadcasts which don't forward. No game had a…

That’s even more impressive!

Games with more than 2 players each with their own private screen was where the PC really started to come into its own as a gaming platform.

But now I miss couch multiplayer with friends trying to yank or knock the gamepads out of each other’s hands..

Re: Yet another macOS privacy protections bypass

#93

Post by tinus_hn » Wed, Dec 02, 2020, 1:47 PM UTC

comex wrote: post #12

Quick note: The report makes it sound like /bin/ls is being given special privileges. That would be reminiscent of many past macOS security issues: processes are treated differently based on their code signature and entitlements, and sometimes that has unexpected consequences. But that's not the case here. /bin/ls has no entitlements. And if I modify the sample project to just call stat() directly rather than invokin…

It is signed by Apple though which might make a difference.

Re: Yet another macOS privacy protections bypass

#94

Post by musicale » Thu, Dec 03, 2020, 1:31 AM UTC

hanche wrote: post #86

musicale wrote: post #84

Earlier quoted context omitted.

This sounds like how stat() normally works. You can read a directory if you have x permission on it. Is the sandbox supposed to block stat() if you don't grant an explicit permission like 'full disk access' but it isn't doing that properly?

You need the r permission to read a directory, in the sense of getting a list of filenames. But the x permission lets you access files and subdirectories if you already know the filename. Of course, you need r permission in the file to read it, but you can always stat() it.

Indeed, I actually meant "read (or check) a specified path/directory status entry" rather than "read a directory" but probably hit submit too quickly.

What this "privacy protections bypass" is doing looks like the former rather than the latter, and it seems like normal behavior if you have x/stat permission.

It could be that Apple's sandbox blocks r/readdir permission but not x/stat permission for some reason.