Hello,
sandbox is a concept in jdk1.1 and it means:
applet runns inside sandbox and local applicaiton
has access to all system resource.
jdk1.2 security manager is much more complex now.
which enable an applet have access to all system
resource if it is signed and the signner has an entry
in policy
file.(Java_HOME/jre/lib/security/java.policy)
also, if java.policy file is changed, a local
application may not be able to access system resource.
There is a tool jarsigner or something in bin dir,
if I remember things right from the Java Security
seminar, it will generate digest for every file
in jar file, so you should not afraid some files
inside
jar file are changed.
hope this helps!
Have a nice weekend!
--- john <[EMAIL PROTECTED]> wrote:
> hi all,
>
> I have been reading this thread for a while now.
> I have a question about the java security in general
> and specifically caters to applets downloaded from
> the internet sites while browsing.
> People have raised security questions when users
> browse and download applets on their local
> computers.
> We have things called as hostile java applets etc.
> here is a reference......
> www.rstcorp.com/hostile-applets/index.html
>
> BUT all these applets run on the JVM and they cannot
> access resources outside the JVM. so where is the
> security problem ? I have been at a loss to really
> get
> to the bottom of this. fine java applications can
> access
> system resources. but not applets. they do not have
> the rights to run beyond the JVM(sandbox).
> please correct me if i am wrong.
>
> thanks
> john
>
> --- Zack Grossbart <[EMAIL PROTECTED]> wrote:
> > Rajesh,
> >
> > The scheme you are discussing is very similar
> to
> > what Cisco does with a
> > lot of their network monitoring code. Cisco used
> > the actual software and
> > not the install. This is probably a better
> option,
> > given that the install
> > can also be tampered with or possibly reverse
> > engineered and rewritten.
> > However, there are some caveats. First, this
> > requires the machine have some
> > unique id. There are a couple of option there,
> but
> > the most popular is Mac
> > address. Some Cisco software uses IP address, but
> > this is prone to
> > difficulties given that the IP address of a given
> > machine is subject to
> > change. Second, this scheme requires a server to
> do
> > authentication. You
> > need to have some server authenticate or else it
> is
> > possible to break.
> >
> > So the bottom line is, any software you install
> on
> > a users machine is
> > theoretically something that the user could get at
> > and change. The only way
> > around this is to have a client and server
> > architecture, and have the actual
> > logic of the application on the server. However,
> in
> > real life the chances
> > of someone wanting to do this are pretty slim.
> > Consider it similar to a car
> > alarm. They don't make your car impenetrable to
> > thieves, but they do make
> > your car more difficult to steal.
> >
> > Zack
> >
> >
> > -----Original Message-----
> > From: Rajesh Nair [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 19, 2000 4:22 PM
> > To: Gayathri Viswanathan; 'Zack Grossbart';
> Gayathri
> > Viswanathan;
> > [EMAIL PROTECTED]
> > Subject: RE: Java security question
> >
> >
> >
> >
> > This would require a self-coded lock or something,
> I
> > presume. It's always
> > good to have obfuscation on the java class code.
> > Like Zack mentions once
> > its in somebody's hands, they could make changes.
> > If obfuscation is really as good as it sounds,
> > wouldn't it be possible to
> > limit the applet that has been installed once to
> > make sure it cannot be
> > copied onto another location? I mean, say your
> > applet has been
> > been installed on machine A. The applet is signed
> > and has access to
> > installed m/c. Applet during installation,
> > creates a lock that identifies this machine
> > uniquely. Person P is able to
> > make a small change say to logo
> > and sells it to Party Q. Party Q runs applet
> > install. Install knows it's
> > being dumped on another m/c. Install
> > spews scary legalise at Q and fails to install?
> >
> >
> > If the applet is being used like normal applets,
> it
> > would have access to m/c
> > that is serving it, right?
> > Does this sound even remotely fair to do?
> >
> >
> >
> > At 02:05 PM 04/19/2000 -0400, Gayathri Viswanathan
> > wrote:
> > >Zack,
> > >
> > >I have already signed my Java applet with a
> > certificate from Thawte. But I
> > >thought that
> > >this means that Thawte certifies that noone has
> > changed the jar file. But
> > >what if after
> > >accepting the certificate, some malicious user
> > wishes to change the
> > contents
> > >of the jar file
> > >by say changing some image files (used for
> > displaying logo) and then
> > signing
> > >it again and then
> > >selling it ? Would obfuscation help in this ? Can
> > obfuscation be used on
> > >applets ?
> > >Is there any other alternative ?
> > >
> > >Thanks.
> > >
> > >-- Gayathri
> > >
> > >-----Original Message-----
> > >From: Zack Grossbart
> [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, April 19, 2000 1:30 PM
> > >To: Gayathri Viswanathan;
> > [EMAIL PROTECTED]
> > >Subject: RE: Java security question
> > >
> > >
> > >Gayathri,
> > >
> > > Obfuscation would help prevent someone
> from
> > decompiling and
> > >understanding
> > >your code, but not from changing it. You should
> > sign your JAR file. Tools
> > >like Visual Cafe have this capability built in,
> or
> > you can write a small
> > >utility to do it yourself using the javax.cript
> > package. If you look on
> > the
> > >JavaSoft site you can get more data about signing
> > JARs.
> > >
> > >Zack
> > >
> > >
> > >> -----Original Message-----
> > >> From: Gayathri Viswanathan
> > [mailto:[EMAIL PROTECTED]]
> > >> Sent: Wednesday, April 19, 2000 12:41 PM
> > >> To: [EMAIL PROTECTED]
> > >> Subject: Java security question
> > >>
> > >>
> > >> Hi !
> > >>
> > >> I have written a Java applet and we wish to
> make
> > it into a product. I
> > have
> > >> the applet setup so that all the
> > >> resources that it needs are within a jar file.
> > How can I make sure that
> > >> other people to whom we may sell the
> > >> software will not be able to disassemble the
> code
> > or change some of the
> > >> image files or property files ?
> > >> Is obfuscation the way to go ? Can anyone help
> me
> > ?
> > >>
> > >> Thanks a lot.
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
