More Perl regex stuff in E

[Mark S. Miller]

At 05:44 AM 4/16/99 , shapj@us.ibm.com wrote:
>That aside, one of the goals of E is to be a *secure* scripting language.  
>What gives you confidence in the code integrity/security of something as 
>large as the Perl regular expression library?


At EC we (Danfuzz, Bill, MarkM) designed (and Bill mostly implemented) an 
enhanced verifier for Java class files, only admitting class files that 
follow capability discipline.  The result was a subclass of ClassLoader 
called "GuestLoader".  It's premise?  Ignoring the Java libraries and 
assuming the built-in verifier actually worked, the instance-only 
single-thread subset of Java is a pure capability language.  That's why the 
history of Java security is so tragic.  As Maxwell Smart might say, "Missed 
it by *that* much."

The GuestLoader's job was to ensure that all statics were transitively 
immutable, and that the only interfaces invoked were either the safe subset 
(by inspection) of the existing libraries, or other code loaded by the 
GuestLoader.  The result is that classes loaded by the GuestLoader are 
transitively immutable and non-authority granting (and therefore confined 
and durable), and that their yield follows pure capability discipline.  (The 
GuestLoader got too hard because we tried to preserve more compatibility 
than, it turned out, we reasonably could.)

So OroMatcher would be safe if it would pass a hypothetical correct 
GuestLoader.  Here are some reasons for confidence:

1) It verifies and has no native code, making it very likely pointer and 
type safe.

2) from its documented semantics, it would not seem to need any static state.

3) from its documented semantics, it would not seem to need to use any Java 
libraries that violate capability discipline.

4) Although it's documented as "thread safe", it also doesn't seem to use 
any threads.


After mocha-ing, we could manually gain confidence in

#1 by grepping for "ClassLoader".  If it never uses the type "ClassLoader", it 
is hard to impossible for it to be taking advantage of the hole in the 
existing Java bytecode verifiers.  Is this true?

#2 by grepping for "static".  Although it is difficult to automatically 
verify transitive immutability in general (what do you do about arrays?), it 
may be easy to do it manually for this case.

#3 by grepping for "import", unsafe method names from java.lang.*, and uses 
of reflection.

#4 by grepping for "Thread".  In the absence of "Thread", "synchronized" and 
"notify*()" are happily semantics-free.


If OroMatcher fails any of these checks, I suspect it would be for an 
incidental reason that we could get fixed -- though I haven't inquired.  If 
it fails and we can't get it fixed, then we'll withdraw the implementation 
but leave its behavior in the spec as a not-yet-implemented feature.  An 
OroMatcher that passes these checks would be known to be capability safe, 
even if it is buggy as all hell.

Patent issues aside, it would be nice at some point to revive the 
GuestLoader work by making it more restrictive in order to make it more 
tractable.

	Cheers,
	--MarkM