The academic community has always gained immensely by its "open" nature. The Internet, although military in orgin, rapidly became an incredible tool for academic research. In particular the Europe-wide academic network has been evolving through the various "Framework" programmes now connecting 30 countries at Gbit/s speeds through Géant.
Security has inevitably been rearing its head (anyone for a multi-Gbit/s denial of service attack?) and clashing with the needs for academic overture.
It wasn't that long ago when the biggest concern for computing centres was to limit access under COCOM rules (relaxed in 1992) to "dangerous nationals". Indeed, my problem in taking delivery of the first Digital DEC3000 alpha-based systems was that they qualified for regulation. It meant that, amongst others, a brasilian PhD student in theory couldn't use them as Brasil hadn't signed the Nuclear Non-Proliferation Treaty.
Then came people trying to poke at supercomputing sites. In the meantime I had migrated to the (now defunct) London Parallel Applications Centre where the problem could no longer be swept under the carpet. A 486sx was pressed into action as a "sniffer" (using tcpdump) on our external link and discovered all sorts of interesting traffic (we weren't the only ones... see Steven Bellovin's famous paper in PDF). Among the traffic was someone from Intel in Israel trying to get in via telnet hacks (this does rather give the time period away, doesn't it?).
If we fast-forward to the current day we are suddenly faced with a security problem of gigantic proportions: the European Data Grid Project.
The idea is to link the LHC particle accelerator at CERN to various academic computing sites around Europe to store, elaborate and trawl the data produced. Furthermore, because of international collaborations, this could well include users from the USA and Asia amongst them. A physicist anywhere on the Internet needs to be able to access the data and run his jobs. From an academic standpoint this is virtually Nirvana: tap into all the computing resources of the world from anywhere in the world.
The first reaction from a security practitioner is: "nightmare!". Followed by ample discussions on how they "certainly forgot" about security. The truth of the matter is fortunately somewhat different: for starters authentication & authorisation uses PKI (An example is the Grid-Ireland Certification Authority). This in itself is not perfect: certificates can be lost, machines on which they reside taken over, but it does mean that the Grid won't become the largest contributor to Seti@Home overnight.
The second reaction takes place when the realisation that the task in hand is far from trivial dawns in the security practitioner's mind. Fine, so let us assume that the authentication & authentication mechanism works. The next daunting issue is that of the code. If all the servers run the same code then breaking into one of them means that you can break into all of them. It is the same principle by which viruses are written for Windows. This means that all of a sudden you might have in your hands the most amazingly powerful DDoS network on planet Earth.
There are a number of solutions: code audit, in the style of the OpenBSD project, running everything on a private network, limiting bandwidth out of the servers, etc. All of these have to face the reality of academic coding: this code is not being developed to military standards. It will not necessarily survive close scrutiny by someone wishing to break into the system and, at the same time, it cannot be expected of the coders to actually audit the code for security flaws. What about running it all on a private network? This simply defeats the concept of a world-wide Grid. Well, then surely we can limit the bandwidth? ... which then renders completely moot the idea of having a 10Gbit/s academic core network.
It is a very difficult problem waiting for someone to work on it.
This has nothing to do with security, feel free to ignore it.
Somewhere in the archives of a local TV station in Lombardy lies an interview with a child held at a park called "Villa Reale" in Milan. It is a beautiful small park, the grounds of the old royal palace in the city centre and is restricted to children and adults accompanying them. The child and his friends were being interviewed about what they wanted to be when they "grew up".
It was 1981, one of the children was eight and replied with pride: "an astrophysicist!". Before then his aim had been to be a cook despite already being heavily into computers but had changed his mind just a few days earlier when the small Telefunken colour TV had shown him the Columbia landing after its first trip in space. He had heard that the future missions would carry "specialists" to study the cosmos and astrophysicists would be amongst them. Then he discovered that the requirements were excellence in mathematics and physics. Sadly he couldn't achieve the latter, only the former, but got close enough to think that his dream was partially fulfilled.
So now the Columbia is lost and people are discussing whether or not we should continue to send men in space as it carries such an enormous cost and risk.
The point of it all is that ever since mankind existed it has been mystified by the skies above: the beauty of the night sky and the desire to comprehend the mystery behind it. This has driven it to incredible conquests: from mathematics to engineering, from navigation to physics. Few efforts have been comparable in magnitude except for the daftness of war and even this should not overshadow the greatness of the other achievements. Now why would mankind even spend this kind of time and effort which makes NASA's budget and effort pale in comparison? Simple: they have been chasing a dream.
And dreams are priceless.
Pretty much everyone and his dog knows the OpenBSD motto of "security by default". Most people haven't the faintest clue as to how complicated it can be to achieve this aim.
One of the most interesting and belaguered areas of operating systems research is that of "marking pages", that is to say defining characteristics for memory pages so that, for example, a memory page holding code is executable but one holding data isn't. Sounds familiar? It should. It is the basic principle by which a buffer overflow works. What might strike you as amazing is that there is more than one processor out there which comes fully equipped with protection against buffer overflows except that nobody bothers to turn it on.
Let us introduce Theo de Raadt, the founder of both OpenBSD and OpenSSH. He is arguably one of the most talented programmers around and also one of the worst choices to pick a fight with or indeed to be on the bad side of. Despite his at times difficult character he can describe technically complicated issues with striking clarity.
In his latest "in depth" posting to the openbsd-tech mailing list he explains in detail the work behind the scenes in the OpenBSD arena to make page protection possible. This is man-years of work, done for the pleasure of being able to raise the bar against buffer overflow attacks on architectures that are being abandoned (alpha, for example).
What I found immediately fascinating is the stark contrast between the "commodity processors", Intel x86 and Motorola 68k, and the "workstation class" processors. The latter can support page protection fully and indeed OpenBSD makes use of it with the latest set of patches.
Is Intel or Motorola to blame? Of course not: these processors, in particularly Intel's, were never meant to power servers. Their humble origins come all the way from the 8080, then 8085, then 8086 and so on. Similarly for the 68k series, an evolution of the MC6800 family (A more complete history of processors is also recommended reading!). As a matter of fact there is space for hope: as Theo notes the new AMD 64-bit processor will come with page protection ("By the way, hammer will not have this problem").