The Next 50 Years of Computer Security: An Interview with Alan Cox

by Edd Dumbill

Author's note: Alan Cox needs little introduction--most will know him for his long-standing work on the Linux kernel (not to mention his appreciation and promulgation of the Welsh language among hackers). Cox is one of the keynote speakers at EuroOSCON this October, where he will talk about computer security.

According to Alan Cox, we're just at the beginning of a long journey into getting security right. Eager for directions and a glimpse of the future, O'Reilly Network interviewed him about his upcoming keynote.

Edd Dumbill: You're talking about the next 50 years of computer security at EuroOSCON. How would you sum up the current state of computer security?

Alan Cox: It is beginning to improve, but at the moment computer security is rather basic and mostly reactive. Systems fail absolutely rather than degrade. We are still in a world where an attack like the slammer worm combined with a PC BIOS eraser or disk locking tool could wipe out half the PCs exposed to the internet in a few hours. In a sense we are fortunate that most attackers want to control and use systems they attack rather than destroy them.

ED: Linux sysadmins see a security advisory and fix practically every day now. Is this sustainable, and does it harm Linux that this happens?

AC: It isn't sustainable and it isn't going to work forever. Times between bug discovery and exploits have dropped dramatically and better software tools will mean better and faster written exploits, as well as all the good things.

I think it harms Linux perhaps less than most systems because Linux security has been better than many rivals. However, even the best systems today are totally inadequate. Saying Linux is more secure than Windows isn't really addressing the bigger issue--neither is good enough.

Alan Cox
Computer Security - The Next Fifty Years

O'Reilly European Open Source Convention

O'Reilly European Open Source Convention
17-20 October 2005
Amsterdam, The Netherlands

ED: You say that we're only just at the beginning of getting computer security right. What are the most promising developments you see right now?

AC: There are several different things going on. Firstly, the once-stagnant world of verification tools has finally begun to take off and people have started to make usable code verification and analysis tools. This helps enormously in stopping mistakes getting into production.

Related to this, languages are changing and developing. Many take some jobs away from the programmer and make it harder or near impossible to make certain mistakes. Java for example has done a lot to make memory allocation bugs and many kinds of locking errors very hard to make.

The second shift has been towards defense in depth. No-execute flags in processors and software emulation of them, randomization of the location of objects in memory and SELinux help control, constrain and limit the damage an attacker can do. That does help. There have been several cases now where boxes with no-execute or with restrictive SELinux rulesets are immune to exploits that worked elsewhere.

SELinux also touches on the final area--the one component of the system you cannot verify, crash test, and debug: the user. Right now, systems rely on user education and reminding users "do not install free screen savers from websites" and the like. The truth is, however, that most users don't read messages from their IT staff, many don't understand them and most will be forgotten within a month. SELinux can be used to turn some of these into rigid policy, turning a virus outbreak into a helpdesk call of "the screen saver won't install."

This last area is very important. We know the theory of writing secure computer programs. We are close to knowing how to create provably secure computer systems (some would argue we can--e.g. EROS). The big hurdles left are writing usable, managable, provably secure systems, and the user.

It's important perhaps to point out here that secure programs, reliable programs and correct programs are all different things. Knowing how to write provably secure programs is very different from saying we know how to write reliable or correct programs.

Pages: 1, 2

Next Pagearrow