That medium.com has a paywall and doesn't want to share content? (is what I learned)
Not getting the same paywall trouble as you but https://outline.com/PZnDHL
What can we learn from the matrix.org compromise?
11–20 of 75 posts
Re: What can we learn from the matrix.org compromise?
#12It's been a few years since I last used Saltstack but if you have access to the master you have instant root on all minions or did that somehow change? salt '*' cmd.run 'find / -delete' and game-over?
Very true, however I'd rather have that problem than an ever multiplying number of user accounts on systems that can su/sudo.
Make golden images with packer, or something similar, and then roll your fleet over.
You should not be running package managers on production servers. Or any of the other things salt, ansible, chef, puppet can do.
Re: What can we learn from the matrix.org compromise?
#13Earlier quoted context omitted.
Okay, I'll bite. What are you calling a dark pattern in assorted agents? Especially given that dark pattern implies intent to harm. (And I say this as someone looking at using an agent: If there's a gotcha, I'd like to know about it)
If you use ssh-agent with default settings it's very easy to accidentally expose access to systems you would not expect via the agent. This seems to be a good post about the problem: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered... The key takeaway is that using ssh -A with default settings allows root on the system you've connected to "to impersonate you to any host as long as you’re connected".
Ah, okay; so it's not the agent that's the problem, but the agent with forwarding. That is a fair point, and probably needs saner defaults or messaging. That said, since I don't use forwarding that should be fine for me.
Re: What can we learn from the matrix.org compromise?
#14Earlier quoted context omitted.
Very true, however I'd rather have that problem than an ever multiplying number of user accounts on systems that can su/sudo.
Make golden images with packer, or something similar, and then roll your fleet over. You should not be running package managers on production servers. Or any of the other things salt, ansible, chef, puppet can do.
As in, no human should run a package manager in prod? (But salt/ansible/etc. running it is fine) Same idea as "if you're SSHing to prod, something is wrong" (where provisioning tools make all changes, logs are all aggregated and delivered in their own tool, and even debugging is built into the app or logging system).
Re: What can we learn from the matrix.org compromise?
#15I have gone on some long verbal rants about the dark patterns (bordering on malicious behavior) exhibited by key agents such as SSH agent, GPG agent, Pageant, and the like. What can you learn from the compromise? Never use an agent. Kill it with fire^H^H^H^H -9.
Okay, I'll bite. What are you calling a dark pattern in assorted agents? Especially given that dark pattern implies intent to harm. (And I say this as someone looking at using an agent: If there's a gotcha, I'd like to know about it)
1) SSH agent will cache your passphrase. While that's the whole purpose of SSH agent, remember that nothing is more insecure than an unlocked secret.
2) SSH agent often starts automatically, frequently without user interaction (even if you specify `-i keyfile`). SSH client and DBus are both culprits here; there's also other culprits too.
3) There are often multiple different agents installed on Linux desktop systems. For example, ssh-agent, gnome-keyring, seahorse, gpg-agent ... the list goes on. Good luck auditing that.
4) Without `-i keyfile`, SSH will present to the remote server all keys, in sequence, cached in your agent (and will cause trouble with active firewalls from too many authentication attempts)
5) If the keyfile you specified in `-i keyfile` does not authenticate, then SSH will fall-back to using keys cached in your agent. That's especially frustrating since you might want to know that the key you specified was rejected!
6) Removing the executable flag from ssh-agent is not a permanent solution: updates will often overwrite the program with a new file and reset the executable bit. Obviously the same goes for renaming the program (that one causes a hell of a lot more noise in logs btw; programs seem to complain more if a program can't be found instead of just not being executable)
7) See also (related) concerns I posted about GPG agent on Stack Overflow [1]
Last, but not least: 8) Hope you don't use a system where agent forwarding or agent caching is turned on in the system settings!
Re: What can we learn from the matrix.org compromise?
#16Earlier quoted context omitted.
Very true, however I'd rather have that problem than an ever multiplying number of user accounts on systems that can su/sudo.
Make golden images with packer, or something similar, and then roll your fleet over. You should not be running package managers on production servers. Or any of the other things salt, ansible, chef, puppet can do.
I can tell you, this is not something that is rare (humans in prod).
Ansible often enables this behavior rather than removes it.
Re: What can we learn from the matrix.org compromise?
#17Earlier quoted context omitted.
Make golden images with packer, or something similar, and then roll your fleet over. You should not be running package managers on production servers. Or any of the other things salt, ansible, chef, puppet can do.
As in, no human should run a package manager in prod? (But salt/ansible/etc. running it is fine) Same idea as "if you're SSHing to prod, something is wrong" (where provisioning tools make all changes, logs are all aggregated and delivered in their own tool, and even debugging is built into the app or logging system).
More as, you should not modify images running in production. By human or machine.
Rather build new images and roll over the fleet. If you need to debug, remove from production (quarantine) and work on it there.
Don't run master / agent setups for ansible / salt anymore. You can still use them for creating images, which are later turned into running VMs. Think about it like containers. Do you update the contents of your running containers, or log into your containers to make changes?
Better yet, use OSes that cannot be modified.
Re: What can we learn from the matrix.org compromise?
#18Earlier quoted context omitted.
If you use ssh-agent with default settings it's very easy to accidentally expose access to systems you would not expect via the agent. This seems to be a good post about the problem: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered... The key takeaway is that using ssh -A with default settings allows root on the system you've connected to "to impersonate you to any host as long as you’re connected".
Ah, okay; so it's not the agent that's the problem, but the agent with forwarding . That is a fair point, and probably needs saner defaults or messaging. That said, since I don't use forwarding that should be fine for me.
And probably it should have been described as an antipattern rather than a dark pattern.
Re: What can we learn from the matrix.org compromise?
#19Earlier quoted context omitted.
If you use ssh-agent with default settings it's very easy to accidentally expose access to systems you would not expect via the agent. This seems to be a good post about the problem: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered... The key takeaway is that using ssh -A with default settings allows root on the system you've connected to "to impersonate you to any host as long as you’re connected".
Ah, okay; so it's not the agent that's the problem, but the agent with forwarding . That is a fair point, and probably needs saner defaults or messaging. That said, since I don't use forwarding that should be fine for me.
Agent forwarding defaults to off, AFAIK. You have to ask for it specifically by either requesting it at the CLI with -A, or adding it to .ssh/config.
It would be nice if people understood the consequences of it, and I do find in my conversations with developers that people generally do not understand that by forwarding the agent, anyone with sufficient access on the remote can use the agent. (E.g., another user w/ sudo.)
Re: What can we learn from the matrix.org compromise?
#20I have gone on some long verbal rants about the dark patterns (bordering on malicious behavior) exhibited by key agents such as SSH agent, GPG agent, Pageant, and the like. What can you learn from the compromise? Never use an agent. Kill it with fire^H^H^H^H -9.
How about using hardware tokens instead? With a right setup, private keys never leave it.