Re: [DotGNU]SEE-IFS

[Bill Lance]

I have been nudging at similar kinds of issues with
VRS.  The assumption now is that the actual exacutable
will be statically compiled and totally selfcontained.
 (This may not be possible, but it's the goal.)  But
the lack of a working file structure does prevent
script based http services, at least directly run on
the host machine. 

If such a thing could be done securily, it would be a
most helpful thing.  But there seems so many ways to
get at files in a *nix system if the root wants to see
them.  And, at least in the VRS model, the
environment's data and code in a nodes host needs to
be as secure from attack from that host as from the
outside.


--- Barry Fitzgerald <address@hidden> wrote:
> 
> Hello, all...
> 
> I've been tossing around an idea in my head and I
> want to bring this one
> up for discussion:
> 
> SEE-IFS.
> 
> 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
> 
> _______________________________________________
> Developers mailing list
> address@hidden
>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com