It’s true that full-disk encryption is useless against remote execution attacks, because the attacker is already inside that boundary. (i.e., As you say, the OS will helpfully decrypt the file for the attacker.)
However, it’s still useful to have finer-grained encryption of specific files. (Preferably in addition to full-disk encryption, which remains useful against other attack vectors.) i.e., Prompt the user for a password when the program starts, decrypt the data, and hold it in RAM that’s only accessible to that running process. This is more secure because the attacker must compromise additional barriers. Physical access is harder than remote execution with root, which is harder than remote execution in general.
You don’t need root (dump memory). You need the user password or to control the binary. Both of them relatively easy if you have user access. For example, change ENV variable to point to a patched binary first, spoof the password prompt, and then continue execution as the normal binary does.
Sure, but there’s still no excuse for “store the password in plaintext lol”. Once you’ve got user access, files at rest are trivial to obtain.
You’re proposing what amounts to a phishing attack, which is more effort, more time, and more risk. Anything that forces the attacker to do more work and have more chances to get noticed is a step in the right direction. Don’t let perfect be the enemy of good.
I am not proposing anything actually, I am implying that this change won’t modify the threat model in any substantial way. Your comment implied that it kind of did, requiring root access - which is a slightly different tm, not so much on single user machines…
So my point is that “The data is safe until your user password is safe” is a very tiny change compared to “your data is safe until your device is safe”. There are tons of ways to get the password once you have local access, and what I strongly disagree with is that it requires more work or risk.
A sudo fake prompt requires a 10-lines bash script since you control the shell configuration, for example. And you don’t even need to phish, you can simply create a SUID shell and use “sudo chmod +s shell” to any local configuration or script where the user runs a sudo command, and you are root, or you dump the keyring or…etc.
Likewise, 99.9% of the users don’t run integrity monitoring tools, or monitor and restrict egress access, so these attacks simply won’t be noticed.
So what I am saying is that an encrypted storage is better than a plaintext storage for the key, but if this requires substantial energies from the devs that could have been put on work that substantially improved the security posture, it is a net negative in terms of security (I don’t know if it is the case), and that nobody after this change should feel secure about their signal data in case their device would be compromised.
No, defense in depth is still important.
It’s true that full-disk encryption is useless against remote execution attacks, because the attacker is already inside that boundary. (i.e., As you say, the OS will helpfully decrypt the file for the attacker.)
However, it’s still useful to have finer-grained encryption of specific files. (Preferably in addition to full-disk encryption, which remains useful against other attack vectors.) i.e., Prompt the user for a password when the program starts, decrypt the data, and hold it in RAM that’s only accessible to that running process. This is more secure because the attacker must compromise additional barriers. Physical access is harder than remote execution with root, which is harder than remote execution in general.
You don’t need root (dump memory). You need the user password or to control the binary. Both of them relatively easy if you have user access. For example, change ENV variable to point to a patched binary first, spoof the password prompt, and then continue execution as the normal binary does.
Sure, but there’s still no excuse for “store the password in plaintext lol”. Once you’ve got user access, files at rest are trivial to obtain.
You’re proposing what amounts to a phishing attack, which is more effort, more time, and more risk. Anything that forces the attacker to do more work and have more chances to get noticed is a step in the right direction. Don’t let perfect be the enemy of good.
I am not proposing anything actually, I am implying that this change won’t modify the threat model in any substantial way. Your comment implied that it kind of did, requiring root access - which is a slightly different tm, not so much on single user machines…
So my point is that “The data is safe until your user password is safe” is a very tiny change compared to “your data is safe until your device is safe”. There are tons of ways to get the password once you have local access, and what I strongly disagree with is that it requires more work or risk. A sudo fake prompt requires a 10-lines bash script since you control the shell configuration, for example. And you don’t even need to phish, you can simply create a SUID shell and use “sudo chmod +s shell” to any local configuration or script where the user runs a sudo command, and you are root, or you dump the keyring or…etc. Likewise, 99.9% of the users don’t run integrity monitoring tools, or monitor and restrict egress access, so these attacks simply won’t be noticed.
So what I am saying is that an encrypted storage is better than a plaintext storage for the key, but if this requires substantial energies from the devs that could have been put on work that substantially improved the security posture, it is a net negative in terms of security (I don’t know if it is the case), and that nobody after this change should feel secure about their signal data in case their device would be compromised.