RE: Java security question
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. >> >> -- Gayathri >> >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >> > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 R&D Informix Software -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Java security question
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
RE: Java security question
I agree with you there. Anyway I guess maybe we should stop this thread now since it's not an actual java-linux issue.. At 07:48 AM 04/21/2000 -0400, Zack Grossbart 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. >>> >>> -- Gayathri >>> >>> >>> -- >>> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >>> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >>> >> >> >>-- >>To UNSUBSCRIBE, email to [EMAIL PROTECTED] >>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >> > > >Rajesh Nair >[EMAIL PROTECTED] >Ph: 913 599 7201 > > >R&D >I
RE: Java security question
You are right, applets are sand-boxed. But applets can be signed thus allowing the user to 'trust' the applet. Once trusted the applets are allowed system resources that otherwise they are deprived of. For example, An untrusted applet is not allowed to obtain the IP address of it's client. It always gets localhost. But a trusted applet can retrieve the actual IP address of a client it is running on among other things. Here is another location of hostile applets: http://metro.to/mladue/hostile-applets/ As you can see security breaches allow untrusted applets to retrieve IP addresses also.. Anyway bottom line signed applets or trusted applets can workaround most of the sandbox securities. Also Gayathri is facing a different issue of how to make sure that her applet code is not engineered after it has been sold. At 07:11 AM 04/21/2000 -0700, john 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
RE: jdb tips?
Nathan, Thank you very much for your help. I now have a working debugger on Linux. I have only one remaining issue. If you must pass in the bootclasspath, is there anyway to only concatenate it? I'm thinking specifically about i18n.jar. This JAR is needed for internationalization support. I can build a bootclasspath with only the stuff I need in it, but I would like to be able to assure that the bootclasspath that is set, and could have been set by the user, is used. Thanks a lot. Zack > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Nathan Meyers > Sent: Wednesday, April 19, 2000 12:16 PM > To: Zack Grossbart > Cc: noisebrain; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: jdb tips? > > > Zack Grossbart wrote: > > > > Nathan, > > > > Thank you very much for your help. I need to pass a > couple more flags than > > just -debug. When I launch: > > > > java -Djava.compiler=NONE -debug > -Xbootclasspath:/path/to/my/jdk/jre/lib/rt. > > jar:/path/to/my/jdk/lib/tools.jar > -Xrunjdwp:transport=dt_shmem,address=agfrn > > ,server=y,suspend=n myClass > > > > Followup to my previous response... > > I overlooked one thing when I tried your example... I run with green > threads by default. It appears that jpda fails with native threads in > Blackdown RC4. Try running "java -green ..." or setting the THREADS_FLAG > environment variable to "green". > > Nathan > > > > > my JVM crashes with the following trace: > > > > Agent password=5i442a > > Transport dt_shmem failed to initialize, rc = 509. > > FATAL ERROR in native method: No transports initialized > > SIGABRT 6* abort (generated by abort(3) routine, also SIGIOT) > > si_signo [6]: SIGABRT 6* abort (generated by abort(3) > routine, also > > SIGIOT) > > si_errno [0]: Success > > si_code [0]: SI_USER [pid: 0, uid: 0] > > stackpointer=0xbfffeb0c > > > > Full thread dump Classic VM (Linux_JDK_1.2.2_RC4, native threads): > > "Debugger agent" (TID:0x40e9e640, sys_thread_t:0x80f8df8, state:R, > > native ID:0x1005) prio=10 > > "Finalizer" (TID:0x40e98320, sys_thread_t:0x80d4c10, > state:CW, native > > ID:0xc04) prio=8 > > at java.lang.Object.wait(Native Method) > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112) > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) > > at > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174) > > "Reference Handler" (TID:0x40e983b0, > sys_thread_t:0x80cec78, state:CW, > > native ID:0x803) prio=10 > > at java.lang.Object.wait(Native Method) > > at java.lang.Object.wait(Object.java:424) > > at > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) > > "SIGQUIT handler" (TID:0x40e983e0, sys_thread_t:0x80ce8e8, state:R, > > native ID:0x402) prio=5 > > "main" (TID:0x40e981e0, sys_thread_t:0x80537a8, state:R, native > > ID:0x400) prio=5 > > Monitor Cache Dump: > > java.lang.ref.ReferenceQueue$Lock@40E98338/40ECE028: > > Waiting to be notified: > > "Finalizer" (0x80d4c10) > > java.lang.ref.Reference$Lock@40E983C0/40ECDB20: > > Waiting to be notified: > > "Reference Handler" (0x80cec78) > > Registered Monitor Dump: > > JDWP Transport Send Monitor: > > JDWP Transport Listener Monitor: > > JDWP Initialization Monitor: > > JDWP Invocation Lock: > > JDWP Step Handler Lock: > > JDWP Thread Lock: > > JDWP Reference Table Monitor: > > JDWP Alloc Lock: > > utf8 hash table: > > JNI pinning lock: > > JNI global reference lock: > > BinClass lock: > > Class linking lock: > > System class loader lock: > > Code rewrite lock: > > Heap lock: > > Monitor cache lock: owner "main" (0x80537a8) 1 entry > > Thread queue lock: owner "main" (0x80537a8) 1 entry > > Monitor registry: owner "main" (0x80537a8) 1 entry > > > > Thanks a lot for your help. > > > > Zack > > > > P.S. I am running glibc 2.1.2. > > > > > -Original Message- > > > From: nathanm [mailto:nathanm]On Behalf Of Nathan Meyers > > > Sent: Wednesday, April 19, 2000 10:38 AM > > > To: Zack Grossbart > > > Cc: noisebrain; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: Re: jdb tips? > > > > > > > > > Zack Grossbart wrote: > > > > > > > > Nathan, > > > > > > > > When I try to launch a JVM with the debug options it > > > says there is no JDWP > > > > implementation available, and I can not find the JPDA or the > > > JVMDI shared > > > > libraries in my JDK. I am using Blackdown RC-4. Do you know > > > if there is > > > > anything that needs to be installed on top of the JDK? > > > > > > You just run "java -debug" and see a message mentioning JDWP by name? > > > I've never managed to see that one, and I have successfully used > > > debuggers that require JPDA (like JBuilder's) with Blackdown RC4. Very > > > strange.
Re: jdb tips?
On Fri, Apr 21, 2000 at 11:19:54AM -0400, Zack Grossbart wrote: > Nathan, > > Thank you very much for your help. I now have a working debugger on Linux. > I have only one remaining issue. If you must pass in the bootclasspath, is > there anyway to only concatenate it? I'm thinking specifically about > i18n.jar. This JAR is needed for internationalization support. Unfortunately, I don't know of any way to concatenate either classpath or bootclasspath - in both cases, the relevant JDK1.2 command line options replace the default value (which happens to be empty for classpath but not for bootclasspath). As for your concern, there really is no way for a customer to preset the bootclasspath. It can't be expressed in an environment variable (unlike CLASSPATH)... the only way to set it, short of hacking components in the JDK/JRE distribution, is with the -X option to the java startup command - and you're the one running that command. Nathan > > I can build a bootclasspath with only the stuff I need in it, but I would > like to be able to assure that the bootclasspath that is set, and could have > been set by the user, is used. > > Thanks a lot. > > Zack > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Nathan Meyers > > Sent: Wednesday, April 19, 2000 12:16 PM > > To: Zack Grossbart > > Cc: noisebrain; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: jdb tips? > > > > > > Zack Grossbart wrote: > > > > > > Nathan, > > > > > > Thank you very much for your help. I need to pass a > > couple more flags than > > > just -debug. When I launch: > > > > > > java -Djava.compiler=NONE -debug > > -Xbootclasspath:/path/to/my/jdk/jre/lib/rt. > > > jar:/path/to/my/jdk/lib/tools.jar > > -Xrunjdwp:transport=dt_shmem,address=agfrn > > > ,server=y,suspend=n myClass > > > > > > > Followup to my previous response... > > > > I overlooked one thing when I tried your example... I run with green > > threads by default. It appears that jpda fails with native threads in > > Blackdown RC4. Try running "java -green ..." or setting the THREADS_FLAG > > environment variable to "green". > > > > Nathan > > > > > > > > > my JVM crashes with the following trace: > > > > > > Agent password=5i442a > > > Transport dt_shmem failed to initialize, rc = 509. > > > FATAL ERROR in native method: No transports initialized > > > SIGABRT 6* abort (generated by abort(3) routine, also SIGIOT) > > > si_signo [6]: SIGABRT 6* abort (generated by abort(3) > > routine, also > > > SIGIOT) > > > si_errno [0]: Success > > > si_code [0]: SI_USER [pid: 0, uid: 0] > > > stackpointer=0xbfffeb0c > > > > > > Full thread dump Classic VM (Linux_JDK_1.2.2_RC4, native threads): > > > "Debugger agent" (TID:0x40e9e640, sys_thread_t:0x80f8df8, state:R, > > > native ID:0x1005) prio=10 > > > "Finalizer" (TID:0x40e98320, sys_thread_t:0x80d4c10, > > state:CW, native > > > ID:0xc04) prio=8 > > > at java.lang.Object.wait(Native Method) > > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112) > > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) > > > at > > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174) > > > "Reference Handler" (TID:0x40e983b0, > > sys_thread_t:0x80cec78, state:CW, > > > native ID:0x803) prio=10 > > > at java.lang.Object.wait(Native Method) > > > at java.lang.Object.wait(Object.java:424) > > > at > > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) > > > "SIGQUIT handler" (TID:0x40e983e0, sys_thread_t:0x80ce8e8, state:R, > > > native ID:0x402) prio=5 > > > "main" (TID:0x40e981e0, sys_thread_t:0x80537a8, state:R, native > > > ID:0x400) prio=5 > > > Monitor Cache Dump: > > > java.lang.ref.ReferenceQueue$Lock@40E98338/40ECE028: > > > Waiting to be notified: > > > "Finalizer" (0x80d4c10) > > > java.lang.ref.Reference$Lock@40E983C0/40ECDB20: > > > Waiting to be notified: > > > "Reference Handler" (0x80cec78) > > > Registered Monitor Dump: > > > JDWP Transport Send Monitor: > > > JDWP Transport Listener Monitor: > > > JDWP Initialization Monitor: > > > JDWP Invocation Lock: > > > JDWP Step Handler Lock: > > > JDWP Thread Lock: > > > JDWP Reference Table Monitor: > > > JDWP Alloc Lock: > > > utf8 hash table: > > > JNI pinning lock: > > > JNI global reference lock: > > > BinClass lock: > > > Class linking lock: > > > System class loader lock: > > > Code rewrite lock: > > > Heap lock: > > > Monitor cache lock: owner "main" (0x80537a8) 1 entry > > > Thread queue lock: owner "main" (0x80537a8) 1 entry > > > Monitor registry: owner "main" (0x80537a8) 1 entry > > > > > > Thanks a lot for your help. > > > > > > Zack > > > > > > P.S. I am running glibc 2.1.2. > > > > > > > -Original Mes
Re: jdb tips?
Hi Zack, Which debugger you used? jdb? What commands did you run in order to make it work? Could you write short notice for other people how to run a debugger? Jacob Zack Grossbart wrote: > > Nathan, > > Thank you very much for your help. I now have a working debugger on Linux. > I have only one remaining issue. If you must pass in the bootclasspath, is > there anyway to only concatenate it? I'm thinking specifically about > i18n.jar. This JAR is needed for internationalization support. > > I can build a bootclasspath with only the stuff I need in it, but I would > like to be able to assure that the bootclasspath that is set, and could have > been set by the user, is used. > > Thanks a lot. > > Zack > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Nathan Meyers > > Sent: Wednesday, April 19, 2000 12:16 PM > > To: Zack Grossbart > > Cc: noisebrain; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: jdb tips? > > > > > > Zack Grossbart wrote: > > > > > > Nathan, > > > > > > Thank you very much for your help. I need to pass a > > couple more flags than > > > just -debug. When I launch: > > > > > > java -Djava.compiler=NONE -debug > > -Xbootclasspath:/path/to/my/jdk/jre/lib/rt. > > > jar:/path/to/my/jdk/lib/tools.jar > > -Xrunjdwp:transport=dt_shmem,address=agfrn > > > ,server=y,suspend=n myClass > > > > > > > Followup to my previous response... > > > > I overlooked one thing when I tried your example... I run with green > > threads by default. It appears that jpda fails with native threads in > > Blackdown RC4. Try running "java -green ..." or setting the THREADS_FLAG > > environment variable to "green". > > > > Nathan > > > > > > > > > my JVM crashes with the following trace: > > > > > > Agent password=5i442a > > > Transport dt_shmem failed to initialize, rc = 509. > > > FATAL ERROR in native method: No transports initialized > > > SIGABRT 6* abort (generated by abort(3) routine, also SIGIOT) > > > si_signo [6]: SIGABRT 6* abort (generated by abort(3) > > routine, also > > > SIGIOT) > > > si_errno [0]: Success > > > si_code [0]: SI_USER [pid: 0, uid: 0] > > > stackpointer=0xbfffeb0c > > > > > > Full thread dump Classic VM (Linux_JDK_1.2.2_RC4, native threads): > > > "Debugger agent" (TID:0x40e9e640, sys_thread_t:0x80f8df8, state:R, > > > native ID:0x1005) prio=10 > > > "Finalizer" (TID:0x40e98320, sys_thread_t:0x80d4c10, > > state:CW, native > > > ID:0xc04) prio=8 > > > at java.lang.Object.wait(Native Method) > > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112) > > > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) > > > at > > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174) > > > "Reference Handler" (TID:0x40e983b0, > > sys_thread_t:0x80cec78, state:CW, > > > native ID:0x803) prio=10 > > > at java.lang.Object.wait(Native Method) > > > at java.lang.Object.wait(Object.java:424) > > > at > > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) > > > "SIGQUIT handler" (TID:0x40e983e0, sys_thread_t:0x80ce8e8, state:R, > > > native ID:0x402) prio=5 > > > "main" (TID:0x40e981e0, sys_thread_t:0x80537a8, state:R, native > > > ID:0x400) prio=5 > > > Monitor Cache Dump: > > > java.lang.ref.ReferenceQueue$Lock@40E98338/40ECE028: > > > Waiting to be notified: > > > "Finalizer" (0x80d4c10) > > > java.lang.ref.Reference$Lock@40E983C0/40ECDB20: > > > Waiting to be notified: > > > "Reference Handler" (0x80cec78) > > > Registered Monitor Dump: > > > JDWP Transport Send Monitor: > > > JDWP Transport Listener Monitor: > > > JDWP Initialization Monitor: > > > JDWP Invocation Lock: > > > JDWP Step Handler Lock: > > > JDWP Thread Lock: > > > JDWP Reference Table Monitor: > > > JDWP Alloc Lock: > > > utf8 hash table: > > > JNI pinning lock: > > > JNI global reference lock: > > > BinClass lock: > > > Class linking lock: > > > System class loader lock: > > > Code rewrite lock: > > > Heap lock: > > > Monitor cache lock: owner "main" (0x80537a8) 1 entry > > > Thread queue lock: owner "main" (0x80537a8) 1 entry > > > Monitor registry: owner "main" (0x80537a8) 1 entry > > > > > > Thanks a lot for your help. > > > > > > Zack > > > > > > P.S. I am running glibc 2.1.2. > > > > > > > -Original Message- > > > > From: nathanm [mailto:nathanm]On Behalf Of Nathan Meyers > > > > Sent: Wednesday, April 19, 2000 10:38 AM > > > > To: Zack Grossbart > > > > Cc: noisebrain; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > > Subject: Re: jdb tips? > > > > > > > > > > > > Zack Grossbart wrote: > > > > > > > > > > Nathan, > > > > > > > > > > When I try to launch a JVM with the debug options it > > > > says there is no JDWP > > > > > implementatio
JComboBox and Focus/KeyListeners
I have been unable to get a JComboBox to report any Key/Focus Events to
listeners. I have checked the archives on the mailing list and the bug reports
and couldn't find the problem reported. I have encountered the problem in both
the Windows and Linux JVM's so I'm wondering at this point whether its my
problem or the JVM's problem. Can a JComboBox not have a Focus/Key
Listener? If not, Why not?
Anyway, here is a small sample code that demonstrates my problem.
When the JComboBox Gains/Loses Focus or has key pressed while its in focus you
should get a little message like:
Component 0 Lost Focus
Component 0 Gained Focus
Component 0 Key Pressed
Well, you get the idea.
---
import javax.swing.JFrame;
import javax.swing.JComboBox;
import javax.swing.JPanel;
import javax.swing.JTextField;
import java.awt.event.FocusListener;
import java.awt.event.FocusEvent;
import java.awt.event.KeyListener;
import java.awt.event.KeyEvent;
import java.awt.Component;
import java.awt.FlowLayout;
import java.util.Vector;
public class testClass extends JFrame implements FocusListener,
KeyListener
{
Vector
componentList = null;
public testClass()
{
JPanel panel = new JPanel(new FlowLayout());
componentList = new Vector();
componentList.addElement(new JComboBox());
componentList.addElement(new JTextField(10));
for (int i = 0; i < componentList.size(); i++)
{
((Component)componentList.elementAt(i)).addFocusListener(this);
((Component)componentList.elementAt(i)).addKeyListener(this);
panel.add((Component)componentList.elementAt(i));
}
this.getContentPane().add(panel);
setSize(320,200);
setVisible(true);
}
public void focusLost(FocusEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Lost Focus");
}
public void focusGained(FocusEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Gained Focus");
}
public void keyTyped(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Typed");
}
public void keyPressed(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Pressed");
}
public void keyReleased(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Released");
}
public static void main(String args[])
{
testClass t = new testClass();
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: jdb tips?
Jacob and others, I have just spent a couple of days making my debugger run on Linux. It was not an easy task, so I thought I would share some of the wisdom I gained along the way. I would point out that these are just the best data I have, and if I am incorrect on any of these point I apologize in advance. First a little background on me. My name is Zack Grossbart. I work for SilverStream Software in Burlington MA (http://www.silverstream.com). We are working on a Linux version of our IDE which includes a debugger. The debugger I am using is the SilverStream debugger. This debugger leverages the Java Platform Debugging Architecture (JPDA) and the Java Virtual Machine Debugging Interface (JVMDI). Here are the lessons I have learned (in no particular order). Debugging does not work using native threads. When I start my JVM with the proper flags to use debugging and my JVM uses native thread my JVM will crash. In order to run with green threads you can either set up your environment, or just use the -green flag. There is no shared memory debugging on Linux. I don't know this for a fact, but the JVM complains when started with socket debugging. You must specify a bootclasspath that contains the location of the rt.jar and the tools.jar. So... Here is what I run when starting the JVM: java -green -Djava.compiler=NONE -debug -Xnoagent -Xbootclasspath:/path/to/j dk/jre/lib/rt.jar:/path/to/jdk/jre/lib/tools.jar -Xrunjdwp:transport=dt_sock et,address=anOpenPort,server=y,suspend=n myClass Here are what the options mean: -green Use green threads -Djava.compiler=NONEDon't use the JIT -Xnoagent Run without an agent -Xbootclasspath:The boot class path -Xrunjdwp: Specifying debug options transport=dt_socket Use socket debugging address=anOpenPort Open the socket at this port Note: I dynamically find an available high port server=yAccept debug clients suspend=n Do not start the JVM suspended As far as being a breakpoint listener, I am writing my own breakpoint listener using JVMDI and JPDA. I don't think this is what most people are trying to do, so I won't mention the gory details. Suffice to say, there is a lot of code. I hope this helps. There is more information about the command line debug options at the following URL, which Nathan sent, (http://java.sun.com/products/jpda/doc/conninv.html). Good luck Zack > -Original Message- > From: Jacob Nikom [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 21, 2000 1:47 PM > To: Zack Grossbart > Cc: Nathan Meyers; noisebrain; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: jdb tips? > > > > Hi Zack, > > Which debugger you used? jdb? > What commands did you run in order to make it work? > Could you write short notice for other people how > to run a debugger? > > Jacob > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Java security question
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
