The post I made was posted onto the GrapheneOS Matrix/IRC channel by someone else. Daniel Micay responded and gave some great suggestions.
A summary of what he said:
- AppArmor can never provide the same kind of security as SELinux.
- Verified boot only for the kernel is meaningless/security theater/doesn’t help.
- Debian is a massive issue, doesn’t provide proper security updates and isn’t a viable choice for building anything reasonably secure. It’s a waste of time to start from Debian.
- We should define a base system, make it read-only and then build verified boot, MAC etc.
- Musl should be used as the libc instead of glibc. Glibc is buggy and overly complex. Musl is missing some very minor security features present in glibc (the glibc implementations aren’t good anyway) so we should add the missing security features to musl.
- Clang/LLVM should be used as the toolchain so we can enable modern mitigations like CFI.
- Systemd is a big problem. They’re hostile towards modern security approaches, adds a huge amount of attack surface / complexity and is developed by incompetent people. PID1 can be tiny and the minimal requirements are like 500 lines of code.
- There shouldn’t be anything like apt. It doesn’t fit into a secure OS design. GPG is insecure and shouldn’t be involved in verification.
- We should provide base OS updates with update_engine. Everything else should be a sandboxed application updated with an application package manager.
- Do the applications like how android does APEX so verified boot extends to applications. APEX ships components as little filesystem images that are mounted and use dm-verity.
- So the base OS is a filesystem image, updating with A/B updates using update_engine and applications should be little filesystem images too.