Re: Mobile Code Security???

From: David Collier-Brown (davecbat_private)
Date: Wed Apr 29 1998 - 06:36:34 PDT

  • Next message: darrenrat_private: "Re: Network Security Certification"

    Steve Bellovin wrote: 
    > I trust ActiveX least of all, then Javascript.  Java at least tried to
    > address the problem.  I don't think it did -- or can -- succeed, but it's
    > a decent attempt.  And, if it had been done right, it probably could
    > have succeeded.
    
    
    Bennett Todd wrote:
    > I think they aren't too well off, as yet. Some of them are wildly
    > unacceptable, as they have no attempt at a ``security'' model; others
    > were designed and implemented by people who tried --- and failed -- to
    > define a workable security model. So far none of them have proven safe,
    > or anywhere near it.
    [...]
    > Peering into the crystal ball, I see applet features in firewalls 
    > ceasing to be > important within the next few years; whether it's by
    > retrofitting kluges like Janus[1], or by seriously integrating some old
    > but not widely used > OS features (e.g. ACLs, Orange Book-style access
    >  control, Domain Type Enforcement, ...) one way or another I think we're
    > going to see improved tools for locking mozillas into boxes on the
    >  desktop.
    
    	Hmmn, from the point of view of the orange/red book world,
    	this might amount to addressing
    		1) trusted path and authentication
    		2) mandatory access control
    		3) discretionary access controls
    		4) labelling, and
    		5) covert channels.
    
    	Trusted path can be approached by signing ``both ways'':
    	the applet makes a credible claim it's from a verifiable
    	provider, and the server convinces the applet that it's
    	really taking to someone credible, and should run. This
    	assumes it's been done for me, and therefor my browse, before
    	we get to this point.
    
    	MAC depends on authentication, and is actually done in the
    	weakest possible sense in a sandbox: everyone is authenticated
    	as ``the untrusted applet'' and gets to run in an environment
    	that can access very little.
    
    	It can be extended to reality (:-)) by associating the
    	user (part of subject) and source (other part of subject)
    	with the applet, so that davecb.sun-signed-applet could be
    	used to discover the process belongs in category ``dave's
    	project'' at level ``unclassified only''.  davecb.unsigned-applet
    	lands in category ``go away, idiot'' (;-))
    
    	Discretionary ACLs work the same way, save I can set them
    	myself, not have them imposed by the security officer.
    
    	Labelling of the example applet will be ``dave's project, 
    	unclassified'', and has to go on every packet that leaves
    	the applet.  We can do this with IPSEC. I assume its done
    	for all packets on the machine, anyway...
    
    	And covert channels remain hard.  MAC will probably prohibit 
    	connections back to the supplying host, so the big pipe
    	is closed, but an applet can semaphore at 20-30 bits per second
    	by issuing lost of ``load other applet'' commands.
    	This one needs careful study.
    
    	Conclusion: can be done.  Lots of work, if it has to be added
    	after the fact to a host that's untrustworthy itself (janus).
    
    --dave
    -- 
    David Collier-Brown,  | Always do right. This will gratify some people
    185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
    Willowdale, Ontario   | davecbat_private, canada.sun.com
    M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:57:22 PDT