WingNews

adrianmsmith|3 years ago

> Any program running in the userspace can read the private key file; have the private keys always been not so private all this time?

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

exabrial|3 years ago

Correction: Mobile phone operating systems are designed to give a single player in the market unlimited access to your privacy while locking out competitors. The operating system is not your friend.

Bravo on the rest, you nailed it.

LoganDark|3 years ago

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

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>

kube-system|3 years ago

Malware has been around for a while. I think the bigger difference is that we’ve started to design computer software with inside threats in mind.

mgdlbp|3 years ago

obligatory https://xkcd.com/1200/

lamontcg|3 years ago

Also related to how the threat model has changed: https://xkcd.com/1200/

EthicalSimilar|3 years ago

You can store them in the Secure Enclave on OSX and require TouchID to use the key for signing.

See: https://github.com/maxgoedjen/secretive

cassianoleal|3 years ago

I've been using Secretive for a long time now. It's a great piece of tech.

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.

Bootvis|3 years ago

That’s why ideally you use a pass phrase with you ssh key. Apps can still read it but not use it.

progbits|3 years ago

Even better, if possible switch to something like PGP keys on Yubikey which prevents exfiltration of the private key, and will only sign things when you enter PIN / touch the device.

grishka|3 years ago

But then enter it every time you need to use the key, thus negating the advantage of just magically logging in without passwords? Because if you use ssh-add and only enter the passphrase once per reboot, apps will be able to use it, that's the point.

TheBrokenRail|3 years ago

Yeah, un-sandboxed programs can access all your user files. That's why there has been such a large push for sandboxing tech like Flatpak. (In general though, you really shouldn't be running programs you don't trust in anything but a VM.)

the_af|3 years ago

I understand the principle, but it seems too onerous on the end user.

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"?

mkmk3|3 years ago

Is running untrusted programs in a VM actually safe? Are they sufficiently secure that it's not trivial to escape one if that's the expected scenario?

dijit|3 years ago

This is how it has been, there are ways around this though:

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.

hdjjhhvvhga|3 years ago

Not that it's very practical, but you can always encrypt your key with a passphrase. Useless for automation, very useful for cases like these.

jesprenj|3 years ago

That's usually my argument when someone mocks me for logging into all my computers as root. Having a separate nonprivileged user and running tons of desktop/shell programs isn't really much better considering all those programs have access to your ~, which is on a PC usually the most inportant directory IMHO.

firejail is a program that helps mitigate this issue by restricting syscalls of programs.

mbwgh|3 years ago

According to the Arch Wiki though, firejail relies on blacklisting by default (although this seems to be subject to change).

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.

nl|3 years ago

This is wrong. Data is important but so too is control of executable programs installed on your computer.

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.

Kamq|3 years ago

Logging in as something other than root also stops you from doing something really stupid to your system without explicit confirmation (usually by running the command with sudo).

LarryMullins|3 years ago

Logging in as root just seems like a silly thing to do, if for no other reason than because so many applications will hassle you about being run as root. Why not just use sudo when you need it?

_def|3 years ago

> have the private keys always been not so private all this time?

It's not called private key because it is very secure and can't be accessed... It's on you to ensure that!

pluc|3 years ago

Only if they run under your user as your private key permission should be only you can read it. Programs running as you are basically you.

suchar|3 years ago

This is true for SSH key, but not for all data on MacOS, e.g. if you run `find ~/Library/Application Support/AddressBook` the OS will ask you if you want to give access to contacts to iTerm2/whatever (unless you have given it before). I'm not aware of a way to create additional sandboxed "folders".

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.

tinus_hn|3 years ago

Yes, it’s actually a bit disappointing they didn’t implement keychain support which makes this a lot harder. But then people would be screaming that Apple is peeping at your private keys, even though Apple can’t see the contents of the keychain.

Karellen|3 years ago

> Any program running in the userspace can read the private key file;

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.

johnklos|3 years ago

That's why it's a good idea to use a passphrase with your key so that the key by itself is not useful to anyone.

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.

mac-chaffee|3 years ago

Yep, same with cookies and cloud credentials: https://www.macchaffee.com/blog/2023/hacking-myself/

calvinmorrison|3 years ago

Use a pass phrase!

njsubedi|3 years ago

I do. Most probably they do too, but since any running apps can access the user’s private keys, the whole security depends on the strength of the passphrase that can be brute forced offline?

vasco|3 years ago

It's totally fine, just do that npm install or `curl | bash`, no need to read anything.

njsubedi|3 years ago

You forgot the /s

(no title)

discuss