I think that the real issue here is that Linux (or unix in general) does has
litte to offer with regard to program capabilities (ref keykos/eros micro
kernel designs). Under Linux, (acl based) one basically has all the
authorisations of the user under which one is running. (setuid programs
being the only program capability). There is no concept of different
program authorisation levels (the things that in S/390 PC/PT, BSA, subspaces
etc were designed for)
In a capability based system userids do not really exist, and all
authorisations are related to the program that is running, and different
programs can have different authorisations. One can imagine that functions
executing from shared libraries can have higher/different authorisations to
that of regular (ie private space) programs.
An implementation of such a scheme could be that program b (which was called
by program a), runs with storage key x, and once program b calls a program
in a shared lib then the program in the shared lib will be running with
storage key y, but still has access to data areas from program b (with
storage key x), but there no capabiliy anymore to reference to anything from
program a. Upon return to program b, there is no capability anymore to
reference anything from the shared lib, but data from program a has
reappeared visible.
Now, it is quite possible to implement such a scheme under linux, but it
would break quite a few things.
I think that from both an integrity design perspective and a compatibility
perspective, one would need to implement this on a higher level than the acl
mechanism (the acl mechanism being the frirst door).
What I would like to try at one point in time (if/when I have the time) is
to run linux like an uml implementation under a capability based
microkernel. This could not only implement capabilities under linux, but
will also add another layer of security to the overall system. (there are
other advantages such as the possibility of partitioning)
The capability based micro kernel can then exploit all the features that the
hardware platform has to offer, in the ways they where designed, whereas the
linux (uml) kernel provides the common/generic interface. Different hw
platforms can have diffrent features, but the linux kernel will be common
across all.
As to modifying the existing S/390 architecture, it is something which
requires great care. Not only because one needs to ensure compatibility
with existing systems, but also to ensure that these 'new features' do not
compromise any future developments. One example where I think a mistake was
made was with the implementation of the linkage stack, it does not look at
the extraction control bit, which effectively broke the virtual machine
concept (not taking sie into account).
There is quite a nice article on architecture design/testing on:
http://www.research.ibm.com/journal/rd/464/vonbuttlar.html
Jan Jaeger
ps One can render (virtual) memory not executable by making it addressable
through an access register (ie data space) only.
From: "John R . Campbell" <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security
Date: Sat, 9 Nov 2002 22:38:58 -0500
The issue is the segmentation; In the IA32 architecture the
segment registers still exist and the LDT (local descriptor
table, describing the segments available to a particular
process) along with GDT (global descriptor table) provide
information about how memory is mapped.
There are some "cookies" in the segment registers that condition
things, but that's not particularly germane. (Two bits are
privilege bits and one bit is the LDT/GDT selector.)
In order to implement a "flat" memory model the IA32 architecture
most often just has the segment registers point to a "flat"
structure where all of the segments start in the same place and
are the same size; Unless things have changed a lot in these
CPUs since the 486, this is how they work.
The ia32 architecture also provided for "call gates" which were
meant to be managed jumps to a privileged state for syscalls.
This doesn't help libraries much though.
The weakness of the flat memory model comes from a lack of
differentiation; Segment limitations are still in place but
the same address can be executed since it's the same byte in
the Code segment, Data segment, Stack segment and Extra segment.
The flat memory model took away the main feature of segmentation
yet gave us a "simpler" mechanism for managing memory.
I'm not sure we can do much to work around this because intel
was the only architecture that really used segment registers-
and that's a throwback to the 80286 and 8086 days.
Neither the MC68K, Alpha or PowerPC really use segmentation in
the same way (although the PowerPC memory mapping implies a
"segmentation" mechanism, it's all faked within a flat address
space) and I don't *ever* recalling anything special in the
old s/360 and s/370 architecture that would render clumps of
memory "unexecutable".
Sorry for the pedantry- I moved a FORTH-based application from
a protected-mode i286 to the 486 by slipping LynxOS under it-
so I had to be familiar with how segmentation worked on both
platforms. The code, data and stack segments always pointed
to the same area of ram for a user program.
--
John R. Campbell Speaker to Machines
[EMAIL PROTECTED]
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
"It is impossible for ANY man to learn about impotence the hard way." -
me
"ZIF is not a desirable trait when selecting a spouse." - me
_________________________________________________________________
Direct chatten met je vrienden met MSN Messenger http://messenger.msn.nl
