Hacker News Reader

Comment by josephg | Hacker News Reader

I don’t care about my /etc/shadow since my machine isn’t network accessible. I’m much more worried about:

- The login cookies I have for my email account, my bank or my GitHub account

- My password vault

- My ssh private keys - which could be used to mess with production systems or make changes to repositories on GitHub without my knowledge

All of this data is extremely small (handfuls of bytes) and could cause lots of harm.

Giving malicious javascript the power to exfiltrate any of these secrets would be a disaster.

View on HN

This is a very interesting insight. The vast majority of traditional unix security mitigations are about securing a multi-user system from malicious users. However a lot of the most frightening threat models now are about using data from a single-user system to hijack session tokens or other secrets and thereby compromise external systems that it has some sort of trust relationship with. That's why you see spearphishing attacks that compromise the clipboard - they are hoping that a useful secret gets copied from a password manager or similar. You don't need to elevate priviledge on the local machine if all the secrets are owned by the user you have compromised, and all these secrets are very small numbers of bytes because they are designed to go into a challenge response type flow.

Yep. The Unix security model feels out of date these days. Who cares about privilege escalation attacks when all my most sensitive data (ssh keys, browser cookies and saved passwords, code repositories, etc) is already readable by every program I run in my user account?

Desktop computing needs application sandboxing like phones have. I find it remarkable that nobody in the opensource world seems to care about this problem.

I think people care, just not enough to deal with the huge PITA that sandboxing turns out to be. It takes a significant amount of discipline - and meticulous detail - to start going down the sandboxing path. In other words, it's tedious and not fun at all.

Cubes OS care about this problem and have a really great solution. If you’re linux-savvy I would recommend it. There are some friction points but it is 100% usable even as a main work OS (I did this for a while in one of the startups I worked for).

As an example of something you can do trivially in cubes, say someone sends you a PDF that you don’t trust you can just right-click on it, the OS will spin up a temp vm, copy the PDF over and start the PDF viewer in the VM. When you’re done, the VM is nuked and any nefarious b/s the PDF tried to do is gone. Typically these tempvms have networking disabled so there’s no way it can communicate with the mothership either.

I have PDFs set to open with firejail. Adds about a second to launch times, acceptable IMO.

If someone has the ability to run things on my machine as my user (which presumably would be required to exploit Retbleed), then they can already read the login cookies for all my accounts, as they are stored in plaintext on disk in Firefox's cookies.sqlite file. Password vault is a little more work, since it's encrypted on disk, but presumably they could just read my password manager's memory space during a period when the database is unlocked. Same with SSH keys, though they'd have to poke into ssh-agent's memory.

Javascript/WebAssembly can run things on your machine but can normally not read any files.

Yep. I’d happily ditch all the spectre and meltdown mitigations if they make my machine run faster - so long as my browser is still a secure sandbox against malicious code.

Anything running natively with my user’s permissions already has access to everything of value on my computer.

It won't prevent theft of ephemeral SSH session keys, but consider using a HSM or at least a TPM (with Termius, or Secretive) for long-term private key storage. 2FA will situationally help with the other concerns. (You can and probably should use 2FA with SSH as well.)

Reply on news.ycombinator.com