Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yet another macOS privacy protections bypass

lapcatsoftware.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Yet another macOS privacy protections bypass

#81

Post by cglong »

Razengan wrote: post #64
juliend2 wrote: post #61

Earlier quoted context omitted.

Voting with your wallet is the crudest & most direct form of power that people have. In a way, it surpasses democracy. So yes, if enough people do it, it does make a difference. 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. People observe what knowledgeable people do, and they tend to learn from it. Y…

> 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.

Re: Yet another macOS privacy protections bypass

#82

Post by codezero »

boogies wrote: post #37
codezero wrote: post #36

Earlier quoted context omitted.

I think they are implying apple can’t control the sensitivity of third party tools across the board, so it’s up to chrome to figure out how to protect your browsing history, and they need to improve their file system layout or APIs to protect their users.

>third party tools >it’s up to chrome https://news.ycombinator.com/item?id=25267165 : > ~/Library/ Safari /LocalStorage because Safari names the files in this directory according to the web sites that you visit! [emphasis added]

Zing, thanks for pointing that out.

Re: Yet another macOS privacy protections bypass

#83

Post by jonhohle »

1vuio0pswjnm7 wrote: post #79

"I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware." Unless we use a more specific term such as "user security" I just assume "security" means company security -- the protection of Apple Inc.'s business. One can argue that the security of the business of Apple Inc. benefits its enthusiastically supportive c…

> Under Apple's definition, there is no such thing as privacy from the company.

What customer privacy is Apple violating customer confidentiality? They have, arguably, the largest end-to-end encrypted messaging system, store user backups and data that they cannot access, are leading in mechanisms to prevent user tracking, and sell hardware specifically designed to reduce data customers are sending to them.

Re: Yet another macOS privacy protections bypass

#84

Post by musicale »

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…

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?

Re: Yet another macOS privacy protections bypass

#85

Post by mleonhard »

Razengan wrote: post #58
joshstrange wrote: post #39

Earlier quoted context omitted.

> 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. Hmm, I wonder if this is the root cause of something my friend group found in high school. We had macs that were locked down and I think it was something the system did vs third-party software but I could be mistaken. Pretty m…

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 function to specify a network address to connect to. I needed to bridge the networks. Linux could bridge ethernet, but the parallel network wasn't ethernet. So I copied the source of a kernel module and modified it to bridge IPX packets between the LAN network and the parallel-cable network.

It worked! My friends and I could play THREE-PLAYER games! DN3D, C&C Red Alert, Quake, Descent, Terminal Velocity, etc. Network drive sharing even worked. It was glorious.

Nobody around me understood what I had done.

Re: Yet another macOS privacy protections bypass

#86

Post by hanche »

musicale wrote: post #84
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…

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.

Re: Yet another macOS privacy protections bypass

#87

Post by rbrtl »

saagarjha wrote: post #65
rbrtl wrote: post #42

Earlier quoted context omitted.

As pointed out by the most voted top level comment it's a kernel issue.

A kernel issue where it fails to adequately enforce the sandbox?

whatever man. you had a good go at me the other day. you're right I'm wrong, and HN is no longer the place for me

Re: Yet another macOS privacy protections bypass

#88

Post by declnz »

jonhohle wrote: post #83
1vuio0pswjnm7 wrote: post #79

"I continue to believe that macOS "security" is mainly theater that only impedes the law-abiding Mac software industry while posing little problem for Mac malware." Unless we use a more specific term such as "user security" I just assume "security" means company security -- the protection of Apple Inc.'s business. One can argue that the security of the business of Apple Inc. benefits its enthusiastically supportive c…

> Under Apple's definition, there is no such thing as privacy from the company. What customer privacy is Apple violating customer confidentiality? They have, arguably, the largest end-to-end encrypted messaging system, store user backups and data that they cannot access, are leading in mechanisms to prevent user tracking, and sell hardware specifically designed to reduce data customers are sending to them.

Umm, no.

https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

https://sneak.berlin/20201112/your-computer-isnt-yours/

Re: Yet another macOS privacy protections bypass

#89

Post by saagarjha »

rbrtl wrote: post #87
saagarjha wrote: post #65

Earlier quoted context omitted.

A kernel issue where it fails to adequately enforce the sandbox?

whatever man. you had a good go at me the other day. you're right I'm wrong, and HN is no longer the place for me

Did I? The only other interaction I had with you recently that I can find is a discussion about Apple's security policies, which seemed fairly reasonable to me.

Re: Yet another macOS privacy protections bypass

#90

Post by higerordermap »

juliend2 wrote: post #61
vevans wrote: post #32

Earlier quoted context omitted.

I don’t know that voting with your wallet works with the richest company in the world, especially when a lot of professionals have to have their devices to do their jobs.

Voting with your wallet is the crudest & most direct form of power that people have. In a way, it surpasses democracy. So yes, if enough people do it, it does make a difference. 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. People observe what knowledgeable people do, and they tend to learn from it. Y…

Yet people here are all blinded by hate on Google but somehow trust on Apple.
Post reply on HN