Security restrictions in signed applets

[icanoop]

I'm working on an applet that has to make network connections.

From what I understand, if the applet is signed by a trusted CA then it

should run outside the sandbox and have the necessary SocketPermission
to use the network. I have my applet signed and certified by Thawte and
the certificate seems to be working fine. However, I am still getting
an AccessControlException when I try to use the network because I don't
have the SocketPermission. Everything I've read says this should be
working.

Does anyone have any ideas why it's not working? How can give my applet
extra permissions without forcing the user to edit the security policy
file?

I'm using the Sun Java Plugin 1.6.0 on Windows with Firefox 2.0.

 

[Andrew Thompson]

I'm working on an applet that has to make network connections.

should run outside the sandbox and have the necessary SocketPermission
to use the network. I have my applet signed and certified by Thawte and
the certificate seems to be working fine.

Describe what it is specifically, that
'seems to be working fine'. Is the user
prompted to grant extra permissions?

...However, I am still getting
an AccessControlException when I try to use the network because I don't
have the SocketPermission. Everything I've read says this should be
working.

That agrees with my understanding, as well
(so long as the user agreed 'yes' when asked
to run the extended permissions applet), and there
is no browser, or plug-in setting that overrides the
end user's ability to extend privileges from an applet
(though I would hope to get some feedback from
whatever was interfering with the applet).

Does anyone have any ideas why it's not working?

Have you tried ..
- refreshing the cache?
- another browser?

...How can give my applet
extra permissions without forcing the user to edit the security policy
file?

Use web-start to launch it (is one way).

I'm using the Sun Java Plugin 1.6.0 on Windows with Firefox 2.0.

What is the behaviour in IE?

Andrew T.

 

[icanoop]

Describe what it is specifically, that
'seems to be working fine'. Is the user
prompted to grant extra permissions?

When I load the applet in a web browser I get a security warning pop-up
window that says:

The applications digital signature has been verified. Do you want
to run the application?

The digital signature has been validated by a trusted source.

The choices presented are Run and Cancel. Then when I click More
Information... I see a list of messages. The one that seems to be
relevant is:

This application will be run without the security restrictions
normally provided by Java.

I of course choose Run. I think Cancel means run without the extra
permissions. I never see anything that specifically requests any
permissions though. I thought running without the normal security
restrictions implies that.

That agrees with my understanding, as well
(so long as the user agreed 'yes' when asked
to run the extended permissions applet), and there
is no browser, or plug-in setting that overrides the
end user's ability to extend privileges from an applet
(though I would hope to get some feedback from
whatever was interfering with the applet).

I have not changed any security policy files from my java installation
or done anything with policytool.

Have you tried ..
- refreshing the cache?

Yes, every time I load the applet.

- another browser?

Yes, IE 7.

Use web-start to launch it (is one way).

I would love to use web start but I need the application to run in a
browser window, not in a separate window.

What is the behaviour in IE?

Same as Firefox. They both are using the Java plugin from Java 1.6.0.

Ryan

 

[Andrew Thompson]

(e-mail address removed) wrote:

(snip extensive replies.)

Thanks - you covered the answers to everything
that I thought might help throw further light on the
problem - unfortunately the replies do not immediately
suggest *any* obvious answer to me.

What you described, was much as I had expected
should work, except for the SAE at the end of it all!

Can you provide a link to the applet, or (better) a
tiny test applet that displays this behaviour?

Andrew T.

 

[Dag Sunde]

I'm working on an applet that has to make network connections.

should run outside the sandbox and have the necessary SocketPermission
to use the network. I have my applet signed and certified by Thawte
and the certificate seems to be working fine. However, I am still
getting an AccessControlException when I try to use the network
because I don't have the SocketPermission. Everything I've read says
this should be working.

Does anyone have any ideas why it's not working? How can give my
applet extra permissions without forcing the user to edit the
security policy file?

I'm using the Sun Java Plugin 1.6.0 on Windows with Firefox 2.0.

Since Mr. Thompson seems to have cleared up all the normal
issues that could have caused this, I have just one question:

Are you calling the offending Applet method from JavaScript?
If you are, the method runs with the same security-settings
as its caller (Javascript), and that is *not* signed. Even if
your applet are granted access, it will fall back to the less
priviledged level of its caller.

If this is the case, the normal way to solve this is outlined
below:
1. Run a background thread within the applet
2. Javascript invokes applet methods which only
change the state of a "runMySecureCode" flag
3. The background thread keeps checking "runMySecureCode".
If the flag changes, the thread resets the flag and call
the priviledged method.

HTH...

 

[icanoop]

Can you provide a link to the applet, or (better) a
tiny test applet that displays this behaviour?

I tried but the tiny test applet I made works as expected! It throws
the AccessControlException when the applet is not signed but works fine
when the applet is signed.

In my real applet I'm not sending the network messages directly. I'm
using JAIN-SIP which is in turn using a DatagramSocket. I'll try to put
a together test applet that uses JAIN-SIP to reproduce the problem.

Ryan

 

[icanoop]

Are you calling the offending Applet method from JavaScript?
If you are, the method runs with the same security-settings
as its caller (Javascript), and that is *not* signed. Even if
your applet are granted access, it will fall back to the less
priviledged level of its caller.

I'm not calling it from JavaScript. I'm calling it from the Swing UI
thread (in a JButton callback method), but I think that's OK. In the
tiny test applet mentioned in my previous post I can send datagrams in
a JButton callback with no problems.

Ryan

 

[icanoop]

OK, it works now.

I needed to sign the jar containing JAIN-SIP as well as the jar
containing my applet. I thought I only had to sign the jar with the
JApplet class in it because I thought permissions were based on the
call stack. In other words I thought calling the SIP library from my
signed applet would give the library the permissions it needed.
Apparently permissions are based on the jar from which the class was
loaded.

Thanks for your help. Forcing me to write up the test applet was what
gave away the problem.

Ryan

 

[Andrew Thompson]

OK, it works now.

(snip solution..)

It's great you sorted it. Thanks for reporting the
cause of the problem.

Thanks for your help.

You're welcome, especially since..

...Forcing me to write up the test applet was what
gave away the problem.

...you had the sense to follow through with the
small test case ( as opposed to whining
incessantly about how others should be able
to guess the answer - which is a common
mistake .

Andrew T.

 

[Thomas Hawtin]

I needed to sign the jar containing JAIN-SIP as well as the jar
containing my applet. I thought I only had to sign the jar with the
JApplet class in it because I thought permissions were based on the
call stack. In other words I thought calling the SIP library from my
signed applet would give the library the permissions it needed.
Apparently permissions are based on the jar from which the class was
loaded.

It's a little bit confusing, and I have made the same mistake you did.

It is based on the call stack. But every frame in the stack has to have
privileged for the permission. And then ever frame in the stack that
created the current stack needs the permission. And so on, right back to
either a natively started thread or a AccessController.doPrivileged
call. (There are some optimisations that go on so that the entire check
need not be done every time.) Java library class are full privileged.

Tom Hawtin

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I needed to sign the jar containing JAIN-SIP as well as the jar
containing my applet. I thought I only had to sign the jar with the
JApplet class in it because I thought permissions were based on the
call stack. In other words I thought calling the SIP library from my
signed applet would give the library the permissions it needed.
Apparently permissions are based on the jar from which the class was
loaded.

This is why it is called codebased security.

If you look at a security policy file it will be
rather clear how it works.

http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#Examples

Arne