It does work as /apps is a complete chroot due to the mounting.
I don’t think there’s any real difference.
A wrapper executes chroot /apps apt $@.
CoreOS has an “update_engine” but I don’t know if it’s the same.
Someone mentioned Silverblue to Daniel and he responded:
no
it’s less bad
it doesn’t do it the way that I’m saying and it probably makes systemd much harder to avoid
I don’t think any of the existing OSes is a useful starting point beyond for use as a way to generate templates
And CoreOS update_engine also has Copyright (c) 2010 The Chromium OS Authors..
At the moment I am not trying to replace Debian / Fedora with a more-secure-by-default base distribution that packages its own wayland, firefox, and whatnot. That would require a complete re-focus. Totally different project. It’s also probably more of an organizational, social challenge. Would need to get a sufficiently big team to join, i.e. maintainers. And then somehow vet these maintainers. Have trusted people that likely won’t be adding backdoors. Before that I also probably would have to try to change Debian / Fedora from the inside first by contributing to them. Also talking to more people from there to see how such an organization works to learn how to build one.
Apt isn’t going to be run inside sandbox-app-launcher as that’d break it so the only isolation would be the chroot which isn’t much isolation at all, especially for root processes.
We can harden chroots to make them give proper isolation like grsecurity’s chroot hardening. I could probably extract that and send it to linux-hardened but I don’t think there’d be much advantage.
There is apparmor-profile-everything’s apt-get profile (it needs more hardening though) for actual isolation but that’s not related to this.
Yes.
FYI AOSiP is a custom ROM, not official AOSP.
What if we were to package a few “core” packages ourselves while still being based on Debian? i.e. whonix.org can provide the base system compiled with clang for CFI, musl etc. with proper security updates.
We don’t need to replicate all of Debian’s packages but just a few main ones.
It’s a compromise for better security but not the best as that’s not currently maintainable.
Yes, I took a lazy shortcut not looking at AOSP update_engine source code and assumed AOSiP wouldn’t be much different. Yes interesting to see the connection of Chromium OS with update_engine.
How’s that possible?
Use newer software from upstream as they release and package? Well, that’s not going to fly well due to dependency issues. New versions don’t work with Debian stable. Would be similar to mixing Debian testing with Debian stable which doesn’t work great.
One could also argue in theory (but not in practice) Debian testing is more secure than Debian stable since Debian testing sticks closer to upstream releases. (That however doesn’t hold true during periods of Debian freeze.)
One could also argue in theory (but again not in practice) that Debian sid is more secure than Debian stable since Debian sid sticks closer to upstream releases. (Ignoring that sid is unstable indeed.)
Debian rolling was an idea but it didn’t materialize.
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.