3 ms·
I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as
by hsbauauvhabzb 5y ago
I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as I know there’s no mechanism for revocation.
What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk
- Foxboron 5y agoKeeping it on a seperate blockdevice allows dm-verity to authentice the device. This value would be signed and secured, so injecting a signed+known library wouldn't work. It would refuse to mount. It should be noted that keeping it unencrypted is only for the traditional linux package manager usecase.
- amarshall 5y agoFrom the article: > The OS binary resources (i.e. /usr/) must be authenticated before being booted into. (But don't need to be encrypted, since everyone has the same anyway, there's nothing to hide here.) Authentication prevents manipulation. Encryption is not necessary to do so (encryption often also authenticates).