Hardware kill switches are unfortunately pretty much useless. For camera it's okay, but a tape is just as good, for microphone, even the gyrosensors can record voice in some quality. And here is the big thing: there is hardly any threat model where blocking the camera would help when the software stack is a burning pile of C buffer overflows from top to bottom. If you can't trust the software to such a degree, then you might as well just not turn on your device. Seriously, what's up with the linux userspace where goddamn gnome initial setup is a C program?! Like, we were okay with lisp code decades ago in more serious things, and nowadays we actually have memory-safe languages with very close to native performance.
But the biggest problem is the lack of sandboxing, and UNIX permissions are way too crude to be of any use. The attacker at worst can't install a video driver, but can easily add anything to your bashrc, or read the content of your browser's cache, etc.
You are right, but Apple does try to rewrite most things in memory safe languages and have been doing so for quite some time now. So it is not exactly GNU/Linux.
I’m no security researcher so do correct me if I’m wrong but I assume you use firejail which is a suid program - a bug here could cause an escape to even become root. And why would you write a sandbox in a memory safe language…
Yes, you're right to be wary of suid, but primarily against local attacks on my laptop. The suid risk for a remote attacker seems rather less than from remote malware without the sandbox. Opinions may differ.
Of course you are correct, it is better than no sandbox, I'm just saying that compared to even the now affected Android, ios OSs GNU/Linux is seriously lacking in terms of security.
But the biggest problem is the lack of sandboxing, and UNIX permissions are way too crude to be of any use. The attacker at worst can't install a video driver, but can easily add anything to your bashrc, or read the content of your browser's cache, etc.