That's right, and the reason for that seeming surprising is that the threat model has quietly changed.
Previously: You owned your computer and your data on it, and you ran programs you trusted e.g. you'd buy Microsoft Word and you'd assume that that program acted in your interests, after all the seller wants you to buy the program. Desktop operating systems originated from the time when this was the current threat model.
Now: Programs don't necessarily act in your interest, and you can't trust them. The mobile phone operating systems were built with this threat model in mind, so mobile "apps" run in a sandbox.
As an example of a modern program that doesn't act in your interest, Zoom "accidentally" left a web server on Macs, even after it was uninstalled. https://techcrunch.com/2019/07/10/apple-silent-update-zoom-a...
I imagine stuff like AppArmor, Snap (or Craft? I forget) sandboxes, or Docker and LXCs help with this. Or do they not?
Apps run in a sandbox and have no access to user files except through "portals", which are secure file pickers essentially.
Not really, it's a on-purpose contrived thing to attempt to deploy sandboxed apps on Windows.
Developing a sandboxed app in Windows means deploying a correctly sandboxed Appx in Microsoft Store, and getting those (Appx deployed on Microsoft Store) correctly working is hell for any non-trivial application.
On Linux, you can attempt (it's not garanteed to work) to sandbox anything you want. Whenever the sandbox even is able to conveniently defend what really matters to you (say, your private key files) is another matter.
Linux was a lot different at that time, in that it actually had a concept of users owning files. If you wanted to access another user's files without their permission you had to jump through more hoops like booting into single user mode.
Bravo on the rest, you nailed it.
They even stopped apologizing and consider their actions a standard practice. You know, Microsoft actually used to asked me if I allow them to send a report when Word crashed. What happened? What changed that they no longer ask me but do whatever they want? Why with each update they insist on "syncing my ms account" and I have to disable it each time?
The take is not uncharitable, it's realistic.
[0] https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
[1] https://old.reddit.com/r/assholedesign/comments/pqi486/samsu...
[2] https://gizmodo.com/apple-iphone-analytics-tracking-even-whe...
[3] https://www.forbes.com/sites/jeanbaptiste/2019/07/30/confirm...
Isn't this ridiculous? "the update does not require any user interaction and is deployed automatically." OK, how do I know if it's installed, or how to get it installed if it doesn't work? I guess there is just no help for me if I don't remember exactly how many auto-update mechanisms I've turned off.
</offtopic>
Even if you don't require TouchID, no apps will be able to upload your private keys anywhere as they never leave the enclave. Sure, they can still _use_ the keys without your permission but to do that they need to be running on the workstation.
That said, TouchID is really not very inconvenient and if you couple that with control persistence, muxing and keepalive on the SSH client, it's really a no-brainer.
Worked smoothly on most systems.
Kind of messy on Windows, because there are so many SSH agent implementations, but GPG4Win's latest version works with the native SSH now. Real progress.
And that’s completely separate to the PIV functionality on the key.
Don’t forget this diagram of all the agents, protocols and bridges you might hit on Windows.
It should be a prime example of what NOT to do.
I tested it now in a minimal privilege account in a chroot on Debian 11 that I use for login from untrusted machines, and strace worked. This is how I captured a password entered into a ssh client password prompt, opened in another login shell of the same user:
-bash-5.1$ ps aux | grep abcde
z 2502130 0.0 0.3 9500 6132 ? S+ 18:04 0:00 ssh abcde@localhost
z 2502140 0.0 0.1 6316 2336 ? S+ 18:04 0:00 grep abcde
-bash-5.1$ strace -p 2502130
strace: Process 2502130 attached
read(4, "s", 1) = 1
read(4, "e", 1) = 1
read(4, "c", 1) = 1
read(4, "r", 1) = 1
read(4, "e", 1) = 1
read(4, "t", 1) = 1
read(4, "\n", 1) = 1
write(4, "\n", 1) = 1
ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0
Doesn't really protect you.
Sandboxing is pretty much the only way to solve this, SELinux does place restrictions but that's a dumpster fire of over engineering that's useless for the end user, who when they find their computer isn't doing what they want it to do, will turn it off.
QubesOS calls this "split ssh" and you can use the same pattern with pgp.
There's also this which I don't see mentioned much: https://manpages.debian.org/unstable/ssh-agent-filter/ssh-ag...
The program doesn’t even need to be malicious, for a while it was a pretty common attack vector to trick browsers into uploading random file you could access.
Later, a malicious ssh server could read memory of the ssh process, potentially exposing the private key (CVE-2016-0777)
Using an agent with an encrypted key protects against that. Using a yubikey/smartcard as well. So it’s strictly a good thing to use it.
A yubikey could potentially protect you against a malicious program that wants to open connections if you have set it up to confirm every key operation - but that comes at a cost. You could also use little snitch to see what network connections a program opens, protecting you against a program trying to use your agent to access a server.
You can have the best of both worlds by storing the key itself in a place that's not readable by many programs. TPMs and other such tech can store a key securely without risk of FunnyGame.app sending it to a remote server. In this model the key would be stored inside a safe, sandboxed place, only readable by an SSH agent or similar, which will prompt for permission to use the key every time. With fingerprint scanners and other biometrics being available even in cheap devices, this process can be relatively seamless.
If you run sufficiently modern SSH software, you can also use external key stores like Yubikeys to authenticate with plain old OpenSSH.
What is a program you "trust"? Something you bought online from a curated app store? Those occasionally have trojans as well. Something you downloaded? Well, if it's open source, that's the norm. Something you build from source? Most people wouldn't be able to spot an exploit hidden in the source code.
So.. it's run everything sandboxed by default the recommendation for regular users? Or is it "do not download or buy anything, it's simply not safe"?
And yes. The recommendation is to not just download and run programs you find on the web.
It may be the only think that works, but it's also an unreasonable expectation. In practice, this makes it a non-solution. A security solution must both work and be reasonably doable by most users.
You should not confuse general wording, which is directed to people who read this website (by the fact that it's y'know posted here instead of somewhere else), with advice for the average person.
I agree. My point was that this point isn't important for a discussion on a niche site.
I agree that this is the state of affairs currently, but this could made to work similarly to how it works on Android perhaps, which has generally good UX for this.
Yeah, that is probably the best solution. Most mobile OSes do that by default now anyways. Desktop Linux has Flatpaks and Snaps. Windows has UWP apps. And I think MacOS has its entitlements system IIRC.
If you don't absolutely trust somethibg, you shouldn't allow it to run unrestricted.
If this isn't the default node -- transparent, where end users must do nothing in particular -- I don't see it succeeding though.
If someone's targetting you with a 0-day exploit that can escape VM sandboxing, having your ssh key hijacked is probably one of your lesser problems. :-/
(If someone has a VM-busting 0-day, they're probably using it in a targetted fashion. The wider that kind of thing is used, the quicker it will be noticed, and patched, and made useless.)
1) use a pgp derived key, this means that anything authenticating will hit your gpg agent and only that, nothing is using that key then
2) load your key and then remove it, which I’ve done before using a LUKS encrypted partition (then load the key into ssh-agent, then remove the volume).
3) Storing your keys in the secure enclave on Apple computers. A little bit onerous if you use an external keyboard without touchID though.
I have a program on my computer that watches for read events in that folder to see if anything actually tries to read an access key. I can publish the source if you want. it uses inotify in linux.
firejail is a program that helps mitigate this issue by restricting syscalls of programs.
Running as root allows a bug in an application like a browser to be exploited and give them root access.
Then they can modify programs like firejail and suddenly things you thought were protected aren't.
This in turn would allow an attacker to login to my servers and other computers leading to a total compromise, as well as breaking trust and integrity of my email (PGP keys).
For my PC a compromise of the user I login as would mean total chaos and compromise, regardless if this user is root or not.
Installation of executable programs isn't limited to the root user, a normal unprivileged one can have them as well. I mentioned firejail because running the browser inside firejail should provide more protection against attacks (provided it's correctly cofigured, as a sibling comment points out), as the attacker couldn't escape the browser sandbox. Though in the current modern world, a browser context compromise could be enough to exploit a power user -- webmail, domain registrar web interface, stored passwords.
I doubt many power users actualy separate their workflow well enough as to change to a different VT (or SSH connection when working remotely) when performing administrative tasks on the computer that require root access. Because if users don't do that and just use a suid binary, like sudo, a malicious attacker with access to code execution in the context of an unprivileged user that elevates privileges with sudo could snoop the password entered by ptrace or simpler means, like a wrapper binary that gets installed without user's knowledge.
(I am by no means a security expert and my opinion shouldn't be treated as useful advice!)
So if it's necessary to be careful about the defaults and to audit everything carefully etc. (i.e. if it's not idiot proof), I am doubtful this is as helpful in practice as one might expect.
I still agree with the general point of your comment though.
I uninstalled sudo and started this habit on personal servers as well when the sudoedit vulnerability was announced, allowing anyone on a macine with sudo installed (regardless of sudoers config) to escalate to root.
It's not called private key because it is very secure and can't be accessed... It's on you to ensure that!
Also, some applications on MacOS are sandboxed, IIRC Mail is one of them. Also, some (all?) applications installed from AppStore. That's the reason I prefer installing applications from AppStore: they seem to be at least somewhat sandboxed.
For development, I try as much as possible to leverage remote development via [JetBrains Gateway](https://www.jetbrains.com/remote-development/gateway/) and [JetBrains Fleet](https://www.jetbrains.com/fleet/). VSCode also has remote development but they explicitly assume that remote machine is trusted (in the security note in the remote extension plugin readme). In the case of JetBrains tools I have not seen any explicit declaration whether remote host is trusted (as in: if remote machine is pwnd then we may as well let pwn your personal machine), but at a glance it seems like there are minimal precautions (if you run web application and open it in a browser, the Gateway will ask if you want to be redirected to a browser etc.)
Probably best scenario for such remote development clients on MacOS would be to put them in AppStore: this way they could leverage sandboxing and in the case of thin client, the sandboxing likely won't limit functionality.
Only programs running as you (or `root`). It's private to you⁰.
Programs running as other users cannot read the file.
(Assuming you've not changed the permissions on the file or the `~/.ssh/` directory)
⁰ and the sysadmin - but if they're not trustworthy they could just replace `/bin/bash` or the kernel with their own version that copied everything you typed anyway.
It's not easy for people to run only trustworthy software, or even software that has been reasonably vetted by others. Not everyone has the aptitude to know how to check for surreptitious file accesses, or have the desire to learn just to make functional use of their computers.
If you're trying to protect against running programs, you also need to protect against key loggers. Using hardware-backed keys and systems like Windows Hello for validation can help with that, as their UI is not easily interceptable.
In the end, there's no perfect way to protect your keys if you have a virus running on your computer.