5 ms·

There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere,

There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to security lists, so the people who actually do the above stop you from using dirty modules. - Yubikeys, etc. Things in the future: - New home directory model. I believe systemd crew are looking into this, so I imagine it'll be hated, even if it does help solve similar issues. - Newer distro models such as fedora silverblue where every process is isolated. I believe this currently mounts your home directory though, so maybe wouldn't work. - New FS layout. Putting .ssh keys in something like .secret/ssh would likely make it easier to not mount secrets into isolated processes and help MACs too.

vsareto 7y ago
Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised
- ownagefool 7y ago
  You're right monitoring doesn't stop your key from being stolen, but it might stop your key being used or for the vulnerability being used again.
- tluyben2 7y ago
  In the way OP suggests, it is; it's kind of like Zonealarm (I have no clue if that still exists; I haven't used Windows for a long time); so it will block a process before sending it and asking the user for permission to send something to X.com. It will do that with every change of X.com. You can allow your process everything of course, but it was convenient enough to block most everything evil while letting through only what I wanted without giving my dev (or any other processes) permission to send to ..
- eitland 7y ago
  That's kind of like saying modern healthcare and vaccines isn't really a solution sinve someone will invariably catch the flu every time a new virus hits, isn't it?
- staticassertion 7y ago
  Monitoring is not a 'solution', but it's quite effective. The real issue is that instrumentation is quite weak, so detecting this attack isn't trivial in most typical monitoring tools. Monitoring is also something that requires expertise, and therefor is something only companies are really going to benefit from. Individual users are not equipped to do this.
C14L 7y ago
I like the idea to solve this on the software side. Be it by peer reviews or by some sort of social network, similar to GitHub, but for security reviews of software. Then you could decide to only install libraries that have a certain number of "good" points on the reviewer network, for example.
- ownagefool 7y ago
  We're already crowd souring this when you run things like npm audit, and github stars, docker downloads, etc. The problem is a tragedy of the commons in where we expect everyone else to do this for us and nobody does. This is why we need to rely on our own developers to actually do the reviewing, and why we have the monitoring to identify when that fails. The more ways you attack the problem, the less likely you're going to be completely owned by a failure. Obviously sticking to a small number of generally trusted popular packages will likely make it easier to establish trust than using 1500 of them. Obviously all this allies to other layers, such as Linux, your cloud provider, your hardware, your CI/CD, your secrets manager.

vsareto 7y ago

Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised

ownagefool 7y ago
You're right monitoring doesn't stop your key from being stolen, but it might stop your key being used or for the vulnerability being used again.
tluyben2 7y ago
In the way OP suggests, it is; it's kind of like Zonealarm (I have no clue if that still exists; I haven't used Windows for a long time); so it will block a process before sending it and asking the user for permission to send something to X.com. It will do that with every change of X.com. You can allow your process everything of course, but it was convenient enough to block most everything evil while letting through only what I wanted without giving my dev (or any other processes) permission to send to ..
eitland 7y ago
That's kind of like saying modern healthcare and vaccines isn't really a solution sinve someone will invariably catch the flu every time a new virus hits, isn't it?
staticassertion 7y ago
Monitoring is not a 'solution', but it's quite effective. The real issue is that instrumentation is quite weak, so detecting this attack isn't trivial in most typical monitoring tools. Monitoring is also something that requires expertise, and therefor is something only companies are really going to benefit from. Individual users are not equipped to do this.

C14L 7y ago

I like the idea to solve this on the software side. Be it by peer reviews or by some sort of social network, similar to GitHub, but for security reviews of software. Then you could decide to only install libraries that have a certain number of "good" points on the reviewer network, for example.

ownagefool 7y ago
We're already crowd souring this when you run things like npm audit, and github stars, docker downloads, etc. The problem is a tragedy of the commons in where we expect everyone else to do this for us and nobody does. This is why we need to rely on our own developers to actually do the reviewing, and why we have the monitoring to identify when that fails. The more ways you attack the problem, the less likely you're going to be completely owned by a failure. Obviously sticking to a small number of generally trusted popular packages will likely make it easier to establish trust than using 1500 of them. Obviously all this allies to other layers, such as Linux, your cloud provider, your hardware, your CI/CD, your secrets manager.