IBM's Multics paper

[Tracy R Reed <treed@ultraviolet.org>]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

As seen on slashdot today...

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485256C2C004B0F0D/$File/RC22534.pdf

I read the entirety of the first paper and parts of the second paper which
is the original Multics vulnerability analysis.

At the top of page 3 of the report (page 5 in your pdf viewed) they
specifically mention SE Linux. They compared Multics 768k bytes of
executable code and data 1767k bytes and suggest that it is far too big to
be secure and that the complexity leading to that large size needs to be
corrected. I infer that due to the Linux kernels monolithic design that
this may not be possible.

Is it realistic to compare a modern OS to Multics? Of course the logical
requirements of multi-level OS security haven't really changed in 28 years
and there is no reason why it should take more bytes to implement the same
ideas so perhaps they are right.

It is also noted that their system never had any exploitable buffer
overflows found due to the way the hardware segmentation worked, the
direction the stack grows (away from occupied stack space instead of
towards such as on x86), the implementation language which has much
better array bounds handling, and the fact that the hardware would not
allow you to execute memory marked as data.

There isn't much we can do about the hardware, stack direction, or
implementation language at the moment. We are stuck with x86 and C for a
good long time it seems. But doesn't x86 hardware now have the ability to
prevent execution of data? That's what Solar Designers patch does iirc.
But there has been some reason for not making it part of the standard
kernel. I've heard about how it prevents intentionally executing
trampoline code on the stack which some compilers use etc. but I have also
heard that this can be fixed. Of course I recall Linus saying that if we
disabled data execution on the stack they would just code around it. I
don't understand how they would do this and if they could do it on x86
surely they could have done it on Multics unless it were very difficult
and if it is that difficult then by all means include the patch in the
kernel! I seem to recall a very long debate about this on the linux-kernel
list some years ago. I have also heard people say that you can get around
the stack direction growth problem although I don't understand how.

I think it is very interesting how Russell's paper "Partioning a Server
with NSA SE Linux" starts out with "The requirement to purchase multiple
machines is often driven by the need to have multiple administrators with
root access who do not trust each other" when that is basically what the
original Multics paper started out with also. The reason they were looking
into multi-level security with mandatory access controls was so that they
could allow secret, top secret, and perhaps even unclassified users, to
all use the same system and thus greatly cut down on hardware acquisition
costs. Having secret, top secret, and unclassified users on one box sounds
rather like you would want them all in their own chroot'd environments or
UML sessions. But from the point of view of the Multics designers, the
steps required to set up domains/chroots or UML etc. are a rather large
kludge with such complexity that it is impossible to verify that all of
the code works as it should with no back doors or unintended side effects.

The parallels between then and now (27 years later) are striking. It is
rather depressing that we are still trying to solve the same problems they
were trying to solve and end up reinventing the wheel.  What's worse is
that our wheel may be rather rickety compared to theirs.

-- 
Tracy Reed      http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior vice-president in charge of Microsoft's Windows development 5 Sept 2002

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]