Previously I discussed the reasons that we need to secure operating systems. We have also covered how current systems work towards security. The next step is to see what is left as a security hazard. Of course the hardware is a risk, and the software running on top of the operating system poses its own risks. If you did not read the other posts in this series I highly recommend going back and reading those first:

Hardware

At the most basic level the operating system relies on our hardware. In the previous article, we took a look at Joanna Rutkowska's list of methods to achieve security in a software system. Joanna Rutkowska also has a wonderful guide to what may be required for hardware security. I highly recommend this as a reading for people that would like to understand the potential for security risks.

Attacks on hardware are already a threat. Certain devices come with cracked firmware to let others listen to what is going on. Other times, the firmware is replaced after the end user starts to use the hardware. Either way the risk is severe. Since an attack on the firmware of one part of the system could lead to a total breach, it is important to look at this as a critical attack vector. Securing the operating system can only do so much if the security is directly undermined by the hardware.

Joanna Rutkowska proposes a method of separating out the firmware and much of the storage and core components to a trusted platform. The trusted platform can then load and control a stateless hardware system, in this case a laptop. This is a great idea, but many may see the necessary protocol around this as an extra burden. This may be especially true for people that are not concerned about security. This burden may make it much harder to reach an adoption level that would make production viable. So while this is a wonderful idea, and may inform our future setup, another method to secure the hardware may be needed.

Software

Assuming we can trust the hardware and the operating system, we still must trust the software running on top of these layers. Viruses, trojans, malware, and improperly configured software will still be a threat. The assumption here is that the operating system will still need to be able to run arbitrary executables as requested for it to be considered a viable replacement for modern operating systems. This means that there is still a requirement for trust and verification for a secure system to remain secure. Of course, systems like Qubes OS could mitigate the risks of problematic software through separated domains. Though this is very much dependent on the user's configuration. This means that the user must be ever vigilant to properly segregate software into separate Qubes so that they remain safe from each other.

What's Left?

The proposed hardware and software safeguards have a fatal flaw. While the operating system can help mitigate this flaw, it cannot complete fix it. The next post in this series will cover the white elephant in the room.

Thoughts? Feedback?

Please feel free to leave thoughts and feedback for this below.