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

Reply via email to