• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

java security

 
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have an applet running that is only working now because I created a policy and added it to the policy.url list in java.security. This doesn't srike me as the right approach for something I'd like to allow access to via internet browser. Is there someone who can walk me though an alternative? Perhaps start by telling me if I have provided enough information. I'm a newbie to this, and I'm guessing that if you know that the work-around I've described works, it's just a matter of using a different approach (properly signed jar with policy inside, for example?). By "walk me through" I mean I'm new to dealing with security issues - I've tried creating a signed jar (using it now) - but don't really know whether I've done all that needs to be done, or even whether this approach will solve the problem in the end. Days and tons of tutorials and documentation and I'm still left with too much trial and error programming to do to figure it out myself. Need detailed guidance.
 
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Signing the applet should be all that's necessary - no policy changes required. There's an FAQ page (http://faq.javaranch.com/java/HowCanAnAppletReadFilesOnTheLocalFileSystem) that has more detailed information and further links on this topic.
 
Roger F. Gay
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK - Now that I've looked through that documentation, here's where I think the problem might be. I don't have this running yet on anything but MSIE. (Opera looks pretty close, and Firefox is chocking on interframe javascript calls.) According to the documentation you suggested, it looks like MS requires signed cab files rather than signed jar files.

In order to create a signed cab file, I need to have Microsoft's Java SDK. Now - as a relative newbie, I don't really mind if I have to do that, but need to ask a question. If I fetch Microsoft's Java SDK and do things like click "run" to install it; .... I like - figure it's going to do something to run Microsoft's Java instead of Sun's. Once I have the ability to create signed cab files, is it difficult to recover ... i.e. get back to using the currently installed Sun Java?
 
Roger F. Gay
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never mind. I had installed some Microsoft stuff and found the tools under ... \Microsoft.NET\SDK\v2.0\Bin
 
Roger F. Gay
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is still a bit deep for me. Like much documentation, it's not entirely understandable unless you already understand it. I'm completely new to java security issues. I tried to run the code as privileged as per example. That didn't work, so I tried to consult the java API documentation to work things out. I am getting an AccessControllerException, and there's a doPrivileged() method, which;

"Performs the specified PrivilegedAction with privileges enabled. The action is performed with all of the permissions possessed by the caller's protection domain."

a-huh ... how are privileges enabled ... what's a caller's protection domain .... .... ... ...

So anyways - I guess I'm back to my initial assessment. I probably need detailed step-by-step guidance.

What I'd really like is a little pop-up the first time a user tries it that asks if they're willing to allow the applet to perform operations it's not usually allowed to do .... if the answer is yes, then permissions are granted .... to the same effect I get when explicitely altering the java.security file. I imagined the approach to doing that had become pretty standard, and hopefully not to complicated.

I hate it when people use their imaginations to much about how things are supposed to work (rather than finding out how they work) - but, seems like there might be some standard method in the security manager that will result in asking a user for permission to do something specific - that way eliminating dishonest permission requests.
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First point: the Microsoft SDK/JVM and CAB files. Don't use those. Seriously. They're waaay obsolete, and it's much easier to make it work with the Sun JVM, because then it should work on all other browsers/JVMs as well.

Second Point: Asking the user for permission. There's really no such concept as asking for permission for a single operation. You could write code that does that, but there's nothing to do it automatically. The way signed applets work is that the user is asked once whether he accepts the certificate with which the applet was signed. That could either be an official one (issued by Verisign for Mighty Big Corporation) or a selfmade one (issued by Roger F Gay for Roger F Gay). If the user accepts it, all operations are allowed, and if he doesn't, the applet won't get loaded.

Soooo .... what you're saying is that despite the jar file being signed, and potentially critical code being inside a doPrivileged section (which is a bit hard to understand, I grant you that), you're still getting the AccessControllerException?
 
Roger F. Gay
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks much for clearing up the cab file thing. Around 11 pm I started thinking that cab files might only be required if using Microsoft's JVM (doesn't matter that I'm using MSIE). I might have gotten a hint from reading. I am using Sun's Java.

Well your conclusion about what I said comes close to what's really happened. I didn't lie intentionally, but my application has gotten complex and it sometimes happens after more than 10-12 hours work in a day, that I start making silly mistakes - like editing a version in one directory and compiling one in another. Around 10 pm, when a recently compiled version went into a loop that was making text flicker through stored responses, I realized the mistake - and also discovered that the work I'd done on making the code priveliged had never been compiled. I made a few attempts to fix it, but was never able to master catching exceptions. So, I haven't tried it as priveliged code yet. Around 10:30, I think I deleted the doPriveliged() code to return to the working state. Once I try again, I'll post code with an explanation of errors. (I usually don't save / back-up non-working code.)

I am concerned about what got me to this point in the first place. I had the applet communicating through sockets without modifying the java policy. The problem started when I switched to using Multicast sockets so I can have several browsers monitoring the same activity at the same time. Sun apparently designed multicasting for use within LANs, and made it problematic by setting their java policy to block its use. So, adding a policy directly on machines that run the ap. seems to be in line with the intent. I'm still hoping however, that ordinary methods of getting permission to run the applet anywhere will work.

Thanks for the explanation. I'll try doPriveliged again and report problems here if I still can't get it to compile. Sample code with handling of doPriveliged() with UnknownHostException for MulticastSocket.joinGroup(address) might be nice if you happen to have any - or just take a shot based on your knowledge of writing doPriveliged() - I tried using sample code in tutorials and from the Java API and kept toggling back and forth between compiler errors telling me -- well, basically that it wasn't right - either the exception was not being handled or - when added (apparently incorrectly) - that I was catching or throwing something not thrown or caught.
[ August 31, 2007: Message edited by: Roger F. Gay ]
 
author
Posts: 9000
19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sliding to the intermediate forum...
 
Roger F. Gay
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Bert Bates:
sliding to the intermediate forum...



OK. This question is related to more advanced stuff - but I don't want to fool anyone. I'm still relatively new to Java, and my problems often actually relate to basic mistakes; like can't get priveliged to work (maybe) because I didn't see a problem with scope in handling exceptions or something (although I had to move on to other issues for a bit, I'm still thinking about this problem in the background - maybe I just didn't scope exception handling properly - maybe). I do however think I've introduced at least one question that's shifted the level - does multicasting require a different approach to security than one-to-one sockets? It certainly seems to (but how do I "fix" it?) I was running one-to-one sockets without needing to create and register a policy.

Not arguing with you - just want to keep an honest perspective so it might be easier for others to understand the kind of help I need.
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Roger F. Gay:
does multicasting require a different approach to security than one-to-one sockets? It certainly seems to (but how do I "fix" it?) I was running one-to-one sockets without needing to create and register a policy.



Applets are allowed to communicate via sockets (or in any other way) with the server they were served from. So if that's what the one-on-one was, then yes, you don't need a policy or a signature. But as soon as the applet is supposed to contact other hosts, then that is generally forbidden, and has to be enabled by one of these means. A list of the things applets aren't allowed to do out of the box can be found here.
[ September 01, 2007: Message edited by: Ulf Dittmer ]
 
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic