[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 4 Feb 2002 22:46:05 +0000 (UTC)
I've been tossing around an idea in my head and I want to bring this one
up for discussion:
First of all, I think we need to look at the function of SEE and perhaps
look towards simplifying it so that much of the labor that SEE seeks to do
is done in any shared libs or API's that we implement. This comes from
IRC conversations and strategy sessions that have occurred. This
streamlines SEE and leaves it up for providing an environment using
existing technology to further itself (more on this later :) )...
However, looking at SEE's primary function (Supplying a Secure Execution
Environment) and listening to talk of making SEE portable and create
jailed shells, I've come up with the following:
SEE Isolated File System.
This is essentially a jailed shell which functions to provide a common
runtime environment, completely isolated by the interface.
The goal would be to provide a minimal internal file structure that is
mounted by SEE and contains a standard Unix|GNU/Linux directory structure.
Placing this inside the realm of SEE control does a number of things:
1) Provides a common file structure to reference in programs.
2) Creates a jailed file system where potentially harmful code may still
access libraries, but not affect external file systems.
3) Creates the potential possibility of harnessing alternate file system
security mechanisms from within a system that doesn't normally support it
(imagine, if you will, a loopfile interface with a minimal SEE-IFS
formatted as reiserfs on a Microsoft Windows fat32 partition, but still
capable of utilizing Unix style file security parameters).
All of this creates a single portable infrastructure where all program
development could be unified.
All comments are welcome. :) Let me know if clarification is needed.
Barry Fitzgerald <=