7 Replies Latest reply: Feb 19, 2011 7:38 AM by 819030 RSS

    Applet security (accessClassInPackage.sun.awt.windows)

    819030
      I have an applet with persistent state. The initial state is supplied as an applet parameter (base-64 encoded) when the applet is loaded, and the applet can save an updated serialized state to the server where it is stored in the DB. This used to work fine, but recently (using a JRE6 provided provided by the manufacturer on a new Windows 7 box) I get a RuntimePermission exception when I call readObject during deserialization:

      accessClassInPackage.sun.awt.windows

      Now I can add this to my java.policy file, but every user would have to do the same for their browser, or I could used a signed jar file, but then everyone would need to install the corresponding certificate. I just want an applet that anyone can access: "write once run anywhere".

      The interesting thing is that this works fine on some other machines. Has the default policy changed? Also, I don't serialize anything AWT-related; the state represents a diagram, but it's a bunch of ArrayLists mostly, with only a transient reference to the panel where the diagram will be rendered. Presumably "transient" is actually honored when serializing?

      Can anyone suggest any other way around this problem, or a way to find out exactly why readObject thinks it needs permission for sun.awt.windows?

      TIA,
        • 1. Re: Applet security (accessClassInPackage.sun.awt.windows)
          sabre150
          816027 wrote:
          or I could used a signed jar file, but then everyone would need to install the corresponding certificate.
          Not really. If you get your certificate signed by one of the standard Certificate Authorities then it's certificate chain will already be in the the Java trust store so the jar signing will be valid.
          I just want an applet that anyone can access: "write once run anywhere".
          Create a public/private key pair and a CSR and submit the CSR to a standard Certificate Authorities and install the certificate they send you in your key store. Then sign the applet.

          >
          The interesting thing is that this works fine on some other machines. Has the default policy changed?
          I know that on an earlier JRE there was a security bug that allowed an Applet to (arbitrarily?) access URLs other than the one that the Applet was loaded from. I can't remember the detail but I'm sure Google will find it.
          Also, I don't serialize anything AWT-related; the state represents a diagram, but it's a bunch of ArrayLists mostly, with only a transient reference to the panel where the diagram will be rendered. Presumably "transient" is actually honored when serializing?

          Can anyone suggest any other way around this problem, or a way to find out exactly why readObject thinks it needs permission for sun.awt.windows?
          Of course you could have found a bug but without seeing the code that tried to write the state I can't judge.
          • 2. Re: Applet security (accessClassInPackage.sun.awt.windows)
            819030
            I just want an applet that anyone can access: "write once run anywhere".
            Create a public/private key pair and a CSR and submit the CSR to a standard Certificate
            Authorities and install the certificate they send you in your key store. Then sign the applet.
            Thanks, but I don't suppose they'll do this for free (nor even cheaply, I suspect), and will need renewing at regular intervals.

            If I'm not serializing anything from sun.awt.windows, what is the reason for this to happen?

            I will of course continue checking my code, but any suggestions as to the easiest way to find out the types of objects in the serialized state I'm loading would be most welcome.
            • 3. Re: Applet security (accessClassInPackage.sun.awt.windows)
              819030
              Hmm. I've just tried it with yet another machine, also JRE6, and it moans when I try to drag & drop diagram elements from the toolbar to the diagram -- access denied to system clipboard.

              I can work around this (I don't need to use drag&drop for this) but it's beginning to seem like every JVM has a different set of permissions from every other! "Write once, run on your development system but nowhere else" perhaps... :-(
              • 4. Re: Applet security (accessClassInPackage.sun.awt.windows)
                sabre150
                An unsigned Applet can have very little access to the client computer and I seem to remember that access to the clipboard was a no-no.

                Yes you will have to pay the CA to sign your certificate. Yes you will have to renew after a certain period; the period depends on how much you are willing to pay.

                I don't know the relevance of sun.awt.windows; I suspect that is just a symptom of your fundamental security problem.

                There is an alternative to getting your certificate signed by a CA. You could use your private key and self signed certificate then your users have two possible decisions. At the security prompt, your users can accept the self signing or not. If not then they cannot run (ALL) of your Applet. If they accept then there is tick box they can tick to indicate they will always trust everything from that certificate. If they tick this box then they will always be able to run your Applet and any other Applets you sign with your private key.

                Using a self signed approach will at least enable you to decide if your problem is a pure security problem.
                • 5. Re: Applet security (accessClassInPackage.sun.awt.windows)
                  819030
                  Checking the raw stream reveals that I am trying to deserialize nothing except a bunch of my own classes, which contain nothing apart from primitive types, Strings, Hashtables and ArrayLists.

                  Can anyone tell me why on earth applet security prohibits me from deserializing fundamental stuff like this? (Not to mention why it is different on different machines...)

                  TIA,
                  • 6. Re: Applet security (accessClassInPackage.sun.awt.windows)
                    EJP
                    Is the stack trace originating from your deserialization code, or from a drag & drop operation?
                    • 7. Re: Applet security (accessClassInPackage.sun.awt.windows)
                      819030
                      I happens during deserialization, at the point where I call readObject().