Re: Mobile Code Security???

[David Collier-Brown <davecb () canada sun com>]

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   | davecb () hobbes ss org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb