141–150 of 323 posts
Also, in popular Linux distributions programs can read unique hardware identifiers like MAC address or HDD serial number, read browser's history and cookies. These valuable data are not protected by Linux.
Earlier quoted context omitted.
I never understood the point of hardware tokens. If the machine it's plugged into it's compromised, the attacker can still use it to sign whatever they want. If the attacker has persistence on your machine, it's as good as stealing the key file. You're basically counting that you can discover the infection before the attacker can use it, or the attacker is unsophisticated so all they do is copy your .asc files (altho…
Yubikeys for example can require a touch on the token to activate it. A dedicated attacker could still trick you into activating the token by waiting for you to do something where you'd need to activate it, but it significantly raises the bar. They also entirely prevent various compromises: * Theft or loss of the laptop does not mean loss of token. * Even if the token gets lost, cracking it will be hard. A dedicated…
Doesn't seem relevant when you probably have FDE enabled.
>* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial.
To be fair, if you weren't using a token, and were just storing the password protected keyfile on your FDE protected computers, there's nothing to "lose" either.
>* Attacks where the attacker can read files do not turn into a compromise of key material.
Only if the keyfile isn't password protected.
>* Even a compromise that allows code execution would require a sophisticated attacker to pivot: You'd need to figure out how to make good use of the acces gained either in a fully automated fashion or be online when the victim has its token plugged in. You cannot collect the key and later figure out what to do. This pretty much rules out attacks such as the one we're discussing here.
Keyfiles are already harder to monetize than other information you can steal off a computer. There's no market for id_rsa/.asc files, but there are for credit card numbers, personal info, bank/email logins. You have to put in the legwork to make money off them (eg. logging into each server and checking what's on it or whether they can be used to pivot elsewhere, seeing who your contacts are to see whether they can be duped using a signed email, or checking whether you're a maintainer for a software project and using your key to sign a malicious update. Therefore, it's safe to assume that attackers interested in your key files are also sophisticated enough to perform the pivot.
Earlier quoted context omitted.
The problem is convenience vs. security, and we all know that even knowledgeable users will often sacrifice the latter for the former. Technically on many OSs you already have dozens of ways to achieve what you're saying. You could spawn a VM, use a different user, use some container framework, use SELinux, etc... The problem is that usability is generally terrible. Or maybe not terrible but bad enough that many peop…
> Look at the modern Linux desktop for instance, you need admin privileges to configure a printer Not for an amount of time that is firmly outside "modern."
Why should Python program have access to SSH keys? Popular Linux distributions, unlike proprietary systems like Android or iOs, cannot protect user's data from malicious programs run by the user. Also, in popular Linux distributions programs can read unique hardware identifiers like MAC address or HDD serial number, read browser's history and cookies. These valuable data are not protected by Linux.
> These valuable data are not protected by Linux.
That’s extremely scary to me.
Why should Python program have access to SSH keys? Popular Linux distributions, unlike proprietary systems like Android or iOs, cannot protect user's data from malicious programs run by the user. Also, in popular Linux distributions programs can read unique hardware identifiers like MAC address or HDD serial number, read browser's history and cookies. These valuable data are not protected by Linux.
On the other hand, Windows and macOS, which, as far as I am aware, also have this problem, are proprietary.
Hence, I don't see why an argument like "unlike proprietary systems" is justified.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
When I first realized that any and all code that I execute, has read/write permissions to most of my filesystem, it blew my mind. The OS grants every process its own unique virtual-memory-space, specifically to prevent malicious/accidental interference with other processes. It seems like the file-system really should operate on a similar principle as well. Every application should run in a sandboxed environment by de…
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
This is part of why I install my Python dependencies from downstream Linux distro repos. I never use virtualenv. If a distro is missing a package I need, it's a simple process to put it together, and the additional steps and checks built into the process stop close to 100% of these issues. Getting a human here also lets you do things like patch out telemetry or other anti-features. Software repositories without a hum…
Indeed. Plus this whole "install the whole python ecosystem for each thing you want to use" is insane.