It could be anything. We can make a small list of commonly used packages. Especially packages that parse untrusted input e.g. a document viewer.
We can package the dependencies too but that might not work out well.
Even without the proper security updates, things like CFI alone would be great.
For now, this is infeasible:
Compiling our own packages or dm-verity? dm-verity sounds pretty feasible.
That’s why my last post was about, yes.
That one might be doable indeed.
Can we use ostree in Debian to accomplish the same?
@madaidan can you focus on getting a firejail alternative off the ground instead of extending scope too much? Perfect is enemy of the good.
What do you think sandbox-app-launcher is?
Good stuff. I thought from this discussion that progress is contingent on getting ostree to work on Debian which can take a while.
Instead of update_engine, we can look into the CLIP OS system updater.
Yubikey is a proprietary meme. non-libre TPMs are not much better and have a history of being vulnerable to divulging secrets.
I am interested to see how well this functions with KVM’s virtual TPM however.
Interesting nonetheless. Would consider contributions. Not going to happen anytime soon due to many tasks.
Most hardware is proprietary. Yubikey/TPMs aren’t any worse.
Everything has had vulnerabilities and I don’t see how TPMs are especially bad. Would you rather have your encryption keys be stored totally unprotected?
Never mind that you can never trust key material generated by the TPM as its RNG is closed and they can keep copies of it at the factory. However any storage feature defects caused by their firmware can never be patched by anyone but them. Assuming they care to invest in security patching and didn;’ go out of business. That’s the problem of designating a closed piece of hardware as your root of trust. A FLOSS smartcard is a much better option.
Proprietary or not is irrelevant. Free software is just as easily backdoored. For example, look at OpenSSL’s Heartbleed. There was a critical vulnerability introduced into a mostly useless part of the software that went undetected for years. Or the Debian OpenSSL bug. Or the hundreds of vulnerabilities in Linux found each month. etc.
You have no idea if any of these were backdoors or not. Backdoors are not going to be obvious. They are going to be obscure bugs that can be passed off as a simple mistake once found and software being open source will not save you.
Open source does not mean “unbackdoorable” or secure.
Even if you had FOSS hardware, you wouldn’t be able to verify that the hardware runs the code they give you anyway.
Some smartcard is also not as secure as a proper TPM.
I am talking about the ability of the user to get/create security updates for the proprietary firmware. I never claimed open was magically bug free.
On measured boot, which seems better than SecureBoot: