nil.enroll(aetheric_username, quantum_class_id) (adric) wrote,
nil.enroll(aetheric_username, quantum_class_id)

  • Location:
  • Mood:

Lessons Learned? Nil

At lunch today I read over a whitepaper from 2002 called "Thirty Years Later: Lessons from the Multics Security Evaluation". It's only eight pages including the references and I recommend any interested party to look it over. Even skimming the few really technical bits, the points are clear in passages such as those I quote below. I got the link to the PDF of the paper was from Crypto-gram, Schneier's newletter: .

Section 6 fairly captures the feel of their findings, starting with:

Security has gotten worse, not better
Today, government and commercial interest in achiev-
ing processing and connectivity encompassing disparate
security interests is driving efforts to provide security
enhancements to contemporary operating systems [27].
These efforts include the addition of mandatory access
controls and “hardening” (i.e., the removal of unnecessary
services.) Such enhancements result in systems less se-
cure than Multics, and Multics, with its security en-
hancements, was only deemed suitable for processing in a
relatively benign “closed” environment [5]. It was con-
cluded that operation of Multics in an “open” environ-
ment would require restructuring around a verifiable secu-
rity kernel to address the threat of professional attacks
using malicious software (e.g., trap doors).

We learned bunches from this study, and applied almost none of that knowledge to any current system. Multics was actually more secure than any system of the time, and yet the flaws in the architecture of Multics were easy to expose, and the researchers invented all kinds of new ways to subvert the system. So much so that they recommended an entirely new development of a secure Multics kernel .. which was never finished. Instead, UNIX was developed and deployed all over for both government and civilian use, along with WinNT, Trusted Solaris and other errors. And then, most damned of all, SELinux ... *sigh*

And as the authors drive home later in Section 6:
Thus, systems that are weaker than Multics are consid-
ered for use in environments in excess of what even Mul-
tics could deliver without restructuring around a security
kernel. There really seem to be only four possible con-
clusions from this: either (1) today’s systems are really
much more secure than we claim; (2) today’s potential
attackers are much less capable or motivated; (3) the in-
formation being processed is much less valuable; or (4)
people are unwilling or unable to recognize the compel-
ling need to employ much better technical solutions.

And then this gem, from 6.2:
In the nearly thirty years since the report, it has been
demonstrated that the technology direction that was
speculative at the time can actually be implemented and
provides an effective solution to the problem of malicious
software employed by well-motivated professionals. Un-
fortunately, the mainstream products of major vendors
largely ignore these demonstrated technologies. In their
defense most of the vendors would claim that the market-
place is not prepared to pay for a high assurance of secu-
rity. And customers have said they have never been of-
fered mainstream commercial products that give them
such a choice, so they are left with several ineffective
solutions collected under marketing titles like “defense in

That's right folks. The reason your OS (`uname`) is not secure-able against attacks that have been documented for 35 years is because no one ever offered to pay for it, and the reason you can't get it that way (if you ask) is ... because no one ever does. Somehow, I think this is all Microsoft's fault, but they had a lot of help. But hey, the new Mac System release (Leopard) has a shiny new Dock, right? *sigh* Ed: Actually MS Vista has much better advances in security than Leopard, but the system is so large and complicated that is difficult to manage, much less secure.
Tags: !security

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded