Linas,
Do I understand you correctly, in that you propose a multi layered system
integrity design, whereby shared libs for example have a different
authorisation from normal apps (almost like a multi ring structure)?
One of the issues I can see with such an implementation in linux, is that
the solutions to achive something like this are going to be very hw platform
dependent. S/390 offers a wealth of features to implement this efficiently
whereas other hw platforms which are more risc based will need to do a lot
of tricks.
In order to keep linux linux, one could think of some kind of micro kernel
which is then hw dependent, and includes all the hw dependent services
(including the above) under which one would run linux.
I think a hw dependent micro kernel/hypervisor would make the above issues
easier to solve.
Such a model is by no means new, AIX V2 (RT) ran under a virtual resource
manager, and AIX/370 only ran under VM, both of these AIXes used the
hypervisor to take care of the hw specifics in one way or another.
Jan Jaeger
From: Linas Vepstas <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security [was: Re: Probably the first published shell
code]
Date: Thu, 7 Nov 2002 11:09:04 -0600
On Tue, Nov 05, 2002 at 10:16:28PM +0100, Ulrich Weigand was heard to
remark:
> Adam Thornton wrote:
>
> (However, changing the Linux tool
> chain and basically *all* applications from a flat address space
I don't see that you need to change *all* apps. This would be only for
apps that really care.
> to multiple address spaces is an *enormous* task; and I'm not
I didn't say it wasn't enormous. Its not tiny, but I'm not sure
its that big either. Depends on how easy you want to make
it for the app developer. Certainly a prototype would not do this
to everything, not by default. If you were to default it in the
wrong way, it would be enormous, and it would break many (most?)
apps.
> convinced this buys you anything w.r.t. security that can't be
> achieved much more easily, e.g. by StackGuard-type compilers.
What I had in mind was the following: preventing an app from
getting write access to a file that the shared library opened.
Or preventing the app from getting write access to a socket
or other IPC that the shared lib created/opened/is using.
Or, for example, the following database stunt: having a database
shared lib memory-map a database file, and then giving the app
read-write access to one page of that memory map, but not all of them.
In some ways, I suppose this is possible today, but its hard & makes you
jump through loops. Client-server loops, in particular. Complex
IPC setups. Haven't you ever noticed how few apps actually use
traditional IPC (semaphores, shmem, etc?) That's because its hard,
its complexity, its crap that the app developer has to design,
and it takes a lot of effort. Today, the only kind of
address-space security that unix has is that one process cannot
corrupt the address space of another process. Thus, if you want to
have address-space security, you *must* write multiple-process apps,
which means you *must* use IPC to coordinate the processes. Ugh.
*That is what I'm talking about.*
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
_________________________________________________________________
Direct chatten met je vrienden met MSN Messenger http://messenger.msn.nl
