Hi,
I'm exploring using CM3 as a platform for hosting untrusted programs
under capability-secure confinement (kind of like SPIN). The
type-safety, disallowing of unsafe features, encapsulation by exported
interfaces / hidden implementations and opaque types of Modula-3, and
the configuring of m3build to use a custom 'pkg' directory to only
allow imports from a subset of the standard interfaces and from custom
capability-secure interfaces I'll provide, go a long way towards
providing a platform for compiling any untrusted Modula-3 source-code
with assurance that it can only do safe things and only use the
interfaces provided to it. However, I need a way to prohibit UNSAFE
and <*EXTERNAL*> (because it provides access to the
supposed-to-be-inaccessible libraries programs are necessarilly linked
with) from being available to untrusted code; and I need a way for
untrusted packages to specify their building without using
quake/m3makefile because quake/m3makefile provide access to the
filesystem and exec. To deal with the quake/m3makefile issue I think
I'm going to design a simple Modula-3 interface that each untrusted
package will implement which is then used to generate a safe/confined
m3makefile. To deal with UNSAFE and <*EXTERNAL*> I could make my own
source-code pre-processor that checks that they aren't used, but I'd
rather the compiler has switches that make it refuse to compile sources
that use them. What I'm getting at is, is there already some way to do
this with CM3? like by using some -Xn@[EMAIL PROTECTED]
to cm3 (I can't find
documentation on these -Xn@[EMAIL PROTECTED]
's anywhere)? And, if these issues are
handled, are there any other ways that untrusted code could get around
being restricted to the set of interfaces I provide it?
Thanks for any feedback,
--Derick Eddington
|
