> From: "G.Grenier" <ggrenier @
grics .
qc .
ca>
>
> What do you think of the Computing Canada's article ("JavaScript escalates
> privacy fears") stating that JavaScript "...has the ability to enter a
> user's Netscape Navigator 2.0 Preferences file, snatch the user's email
> address and forward it to another Ineternet address without the consent or
> knowledge of the user. ..."
It is trivial for Argus's Decaf product to separate out those
resources available within the VM/browser from those available
to the user when operating outside of the browser. That is, the
browser, any applets it runs, and any "descendents" of the applets
can be treated with the same security restrictions. A few lines
of code would have to be added to the VM/browser if you wanted
the applets to run in a different Decaf environment than the
VM/browser itself, but other than that, there is no problem at all
in solving problems like this.
In fact, with Decaf, you could write an applet that could run either
a program or function in a more restricted environment than the
"parent applet." BTW, all of this applies even if the VM/browser
is running as superuser/root.
A brief explanation of Decaf for those who haven't tried it:
Decaf puts read/write/execute restrictions on a per-environment
basis rather than a per-user basis. The user ID is not used.
The decaf environments can be either hierarchical or compartmentalized
or both.
NOTE: This is *not* a B1 labeling scheme, although you can run decaf
on top of a Solaris 2.x system with Argus's C2, B1, and trusted
network modules installed. Another interesting configuration is
to run a firewall on top of all the various Argus security modules.
The C2 module gets rid of superuser on unix -- that solves lots of
problems with all kinds of network daemons. Imagine: Solaris with
no superuser, restricted operating environments unrelated to chroot
or UID, and MAC labels.
Also, when operating in *any* decaf environment, there are some
things that root can no longer do, such as create new devices.
This prevents a rogue applet from creating a new device pointing
at the raw disk or memory and then trying to bypass any OS security.
paul
------------------------------------------------------------
Paul McNabb mcnabb @
argus .
cu-online .
com
Argus Systems Group, Inc. TEL 217-384-6300
1405A East Florida Avenue FAX 217-384-6404
Urbana, IL 61801 USA
------------------------------------------------------------
Follow-Ups:
|
|
