According to this there are compelling reasons for caution when installing obfuscated binaries. Knowing this, how can running binary blobs as a part of the Linux kernel be acceptable from a security point of view? There exists a blob-free version of the kernel. The motivations behind that project seem to be primarily ideological. But what kind of risks do users of non-free driver modules actually face? Can a binary blob contain a rootkit designed to take over or open a backdoor into the entire system? How could such a backdoor be detected?
- From a security, and even ideological, point of view; blobs are unacceptable.
whatever people say, they are trying to dissuade you from the importance of this issue.
- the risks users of non-free software face, be it a firmware blob, driver blob, or Microsoft Windows, are vastly unmeasurable. and while it is safer using any Linux distro than Windows, it doesn't mean that any Linux distro is secure.
- blobs, depending on their size, can do just about anything, they are little programs after all.
- as for detecting backdoors and other security flaws, there is only one way, and it is quite simple;
publish the source code. the previous answer points out that:
"A binary will be much faster than other code." Liar, Liar, Pants on Fire.
a blob will only make the final compiling process of the program faster, not the program itself,
but regardless of program performance decisions,
there's no reason not to publish the source, and compiling instructions of that "blob"
and anyone telling you otherwise is either lying, of some kind of NSA, FBI agent.
if you are interested in a 100% FOSS (free and open source) operating systems,
that consciously maintain their code to be blob free, here is a link: Free GNU/Linux distributions
other relevant links:
What is free software?,
The main reason they incorporate binaries is for speed. A binary will be much faster than other code, so it's handy since it's so deeply built in to the kernel especially.
How can this be acceptable? Because it is assumed that they were not made with malicious intent. If you are truly worried about this, you can compile the kernel from scratch yourself so you can vet the code that goes into these binaries yourself. The second part is making sure that they havent changed to something thats unknown.
By non-free driver modules I assume you mean something purchased for use on the system. They are exactly the same amount of security as anything proprietary. Meaning that you don't know what's inside them and so if you trust the manufacturer of the software then great! let's hope they didn't feel malicious before they compiled down to binary.
Could a binary be designed to rootkit a system? Absolutely!! This is the same point I just made. Even a seemingly harmless binary could have a replica made that did the same thing and also was a rootkit.
How could such a backdoor be detected? Several ways. The best answer is file integrity monitoring. Even something that takes a simple MD5 or another simple one way hash of simple locations like /etc or just each of the binary files to make sure that someone hasn't changed them. And of course the usual suspects like antivirus, antispyware, and a good firewall.