Future Operating Systems Will Be Built For Security

As far as security goes, the operating system of the future is, in many ways, here today. Led, somewhat ironically, by Microsoft Windows, operating system vendors and some other software vendors have been making their products more secure by default. They also have been providing tools and best-practice guidelines for application developers to improve security.

If everyone adopted the most current versions of software and followed state-of-the-art practices in software development, the future would be here today. Alas, things are never that easy.

The Internet caused the escalating software security problem, and the protection of web browsers and other Internet-facing software has been the greatest imperative of security developers. The techniques designed to protect these programs will find their way into other applications and the core of the operating system itself.

Recent security research has found limited cracks in the walls put up with DEP (data execution prevention), ASLR (address space layout randomisation) and other systemic protection technologies. But the developers of these protections understand that they’re not impenetrable barriers; they are obstacles put in the way of exploits, making it harder and harder to accomplish them. The more such obstacles that are put in place, the harder it is to carry out a real-world exploit — as opposed to a laboratory one — and the less serious the implications of the exploit will be. This is called defense in depth.

The good news about these techniques is that they should not change the way applications operate — except for certain egregious cases — and you get the security for free. They make some programming techniques, self-modifying code in particular, the inherent problems they should be. The real problem, which we have been experiencing for the many years that DEP and ASLR have been implemented in Windows, is that many applications we use don’t opt-in to them.

A history of improvements

There are other systemic improvements that OS developers can and will implement. One of them, sandboxing, has a long history in managed environments such as Java. In fact, not too long ago, many felt that Java and such managed environments were the future of operating systems. There’s still something to that, but the security records of Java and .NET haven’t been especially impressive, even though they were supposedly designed with that objective.

Managed virtual environments improve security by managing memory for applications, by protecting memory corruption errors, for example. The price of this is mostly system performance. The problem is that the environments themselves can have vulnerabilities, and quite a few of these have surfaced over the years. Plus, there are so many other classes of errors in addition to memory errors, so applications aren’t secure purely by being written in a managed environment.

Still, memory corruption errors are important, and the trend toward managed code is a net plus for security. This is one reason a lot of corporate development has moved to such environments — from Java to ASP.NET. Writing conventional code that is carefully scrutinised for security vulnerabilities is hard and requires expertise you may not have. Writing managed code takes care of at least the straightforward errors. And, once again, it shouldn’t make anything harder unless you are relying on techniques you shouldn’t be.