Brevity.
It’s good to be innovative. Such as in case of Whonix shipping kloak by default is a win. That threat model has been demonstrated through a proof of concept already. Proactive yes, but in this case of remounting /etc with nosuid the benefit of the change doesn’t have a strong rationale.
There’s a huge amount of things which won’t make sense from our point of view. For example there is the hello package which most users won’t know and won’t install. I am using it as an example here. No need to pick on that particular maintainer of that Debian package. Why allow installation of that package? What if that maintainer turned evil and somehow included a backdoor in the hello package? To prevent such a backdoor from doing damage, there could be an apt wrapper that prevents installation of that and other packages which most users will probably never need. I am not supposing to invent an apt wrapper for this hypothetical scenario. It would be worse having that code than having that risk.
The superior reason from preventing untrusted root writing anything malicious /etc is apparmor-profile-everything. Once that’s done, there is no need for an additional layer for preventive of suid creation in /etc. Many goals can be implemented in multiple ways but I don’t think we should implement every goal using duplicate implementations.
For example, remount-secure all inside initramfs (supposing that is possible) would be fine. Then that shouldn’t be fully duplicated with remount-secure again using systemd.
I cannot imagine any accident how any system administrator would create an suid binary and store it in /etc. And if a system administrator chooses for some reason to but a suid binary there then there’s no need to interfere with that choice.
It’s one valid strategy to optimize is to add safeguards for every cases no matter how likely. However, also Focus on low-effort maintainability is important which includes keeping the amount of lines of code small or even reducing it (i have some plans such as “tb-updater → binaries-freedom”…). By keeping the code size small it’s also more contributor friendly since more easy to understand, easier to review.
It’s in the table there but there’s no rationale for it either.
Keeping notes here now:
I not not sure if Mount /rw and /home with nosuid + nodev · Issue #5263 · QubesOS/qubes-issues · GitHub is indicating that flatpak and snap also break when using nosuid on /home.