Hacker News Reader

Comment by michaelt | Hacker News Reader

> This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user.

Isn't that a smartphone-and-app-store-only thing?

As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user.

That's why e.g. PC games ship with anti-cheat mechanisms - because PCs don't have a comprehensive attested-signed-code-only mechanism to prevent nefarious modifications by the device owner.

View on HN

> As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user.

macOS sandboxing has been used for this kind of thing for years. Open a terminal window on a new Mac and trying to open the user’s photo library, Desktop, iCloud documents, etc. will trigger a permissions prompt.

Interesting, it's a few years since I've used a Mac.

Descriptions of this stuff online are pretty confusing. Apparently there's an "App Sandbox" and also "Transparency Consent and Control" - I assume from your mention of the photo library describing the latter?

How does this protection interact with IDEs? For some operations conducted in an IDE, like checking out code and collecting dependencies the user grants the software access to SSH keys, artifact repo credentials and suchlike. But unsigned code can also be run as a child process of the IDE - such as when the user compiles and runs their code.

How does the sandboxing protection interact with the IDE and its subprocesses, to ensure only the right subprocesses can access credentials?

They added sandboxing in the 2000s, which does mandatory access control (e.g. you can write a rule that Firefox.app can’t access ~/Library/Keychains) and expanded it with containers (not OCI) which standardize the layout starting with the App Store so they all follow common restrictions for what they can access and where they store different classes of data. Those policies are inherited by child processes (e.g. your Terminal.app permissions apply to CLI tools you run in its windows but not something you start by logging in via SSH) so much of the effort has been standardizing the UX – don’t access photos directly, use the system picker which allows the user to select subsets, etc.

https://developer.apple.com/documentation/security/app-sandb...

So the answer to that question depends on what permissions the IDE has asked for and been granted. It’s likely that the first time you opened a shell inside the IDE you’d get promoted for permission to access protected locations the first time you ran a command which did something protected, but they could ask for something like full disk access at install time to avoid many prompts.

macOS and Windows’s native keychains both support this - they encrypt the secrets with a key that is not accessible to apps that run with user permissions without sudo (macOS) or elevation (Windows). The actual user can still access them, but a normal app (other than the one that stored the secret in the keychain originally) running as that user cannot do so directly.

Reply on news.ycombinator.com