SCJEA Sample questions on Sun's site (whoops)

[Amanda Waite]

Hi all,
I'm taking part 1 tomorrow, I should be ok but there are a couple of things that are bothering me. Of the 10 sample questions on Sun's web site two have dubious answers. The first is the one that ask's about the features of https. The answer says that it's Connection-based and secure. Ok, secure is a given, but what about connection-based. It's reasonable to say that http is connectionless as it does not retain state, but https uses a negotiated key for communication between endpoints. I wonder if this is why they say that https is connection-based. The trouble is, it's still http regardless of what happens at the transport layer.
Also question 10, says that the following statement is true:
"Classes loaded from a jarfile on a remote source can sometimes be trusted even if the jarfile is unsigned. "
This appears to be false at first, but it may just be a case of semantics. I've been trying to think of a case where this would be true but I've not had any luck. Anyon have any idea's (on either question).
Thanks
Amanda

Sorry for not using a valid name, the 3 warnings that were displayed when registering (one in 24pt text) completed escaped me. I guess that I've just registered at too many sites (

[Amanda Waite]

In response to my own question.
The answers given for both questions are correct, it's just that the way they are phrased is misleading. Notice that the correct answer to question 10 doesn't mention the word 'browser'. The other answers all do except for the last answer reads well but is obviously wrong.
Amanda
Just in case you haven't seen it here's question 10 in full:

10. Which statement is true?
Classes loaded into a browser from the local network are trusted.

Classes loaded into a browser from remote sources are trusted if they are signed.

Classes loaded into a browser from remote sources are trusted if they are in a signed jarfile.

Classes loaded from a jarfile on a remote source can sometimes be trusted even if the jarfile is unsigned.

Classes loaded from a signed jarfile are trusted if the public key associated with the jarfile's signature is marked as trusted in the keystore.

[Joe Nguyen]

Could any one explain why a, b, c are not the right answers. I think classes load from local host are trusted since they are not loaded by AppletClassLoader. In addition, applet will be trusted if it is signed. SignJar file includes classes and digital fingerprint (using private key to encrypt message digest of these classes). Once, we can verify jar file with the public key, this will be trusted. I know java 2 introduces protection domain and policy, but they mostly specify the user access (authorization to perform certain operations...).
Thank in advance

[Walter Vetrivel]

hi, which sample questions does amanda refer to in this post,
I have not seen these, only the ejb quiz is available on the sun site, Thanks
Walter

[Rahul Mahindrakar]

Walter,
There were some sample questions available on the sun site upto some weeks back. Unfortunately, Sun has discontinued this part of the site.

[Walter Vetrivel]

Thanks for the clarification.
Walter

[Walter Vetrivel]

The Question and answer for question 10 does not seem right.
Classes loaded into a browser from the local network are trusted.
This can be considered false since only classes from the same jvm will be trusted and not from a different jvm in the local network.
Classes loaded into a browser from remote sources are trusted if they are signed.
classes can be signed only if they are in a jar file, so this is false.
Classes loaded into a browser from remote sources are trusted if they are in a signed jarfile.
classes can be given extra privileges if signed but still cannot be trusted fully, hence this can be considered false.

Classes loaded from a jarfile on a remote source can sometimes be trusted even if the jarfile is unsigned.
This looks like the most improbable answer, and I don't understand how it is right.
Classes loaded from a signed jarfile are trusted if the public key associated with the jarfile's signature is marked as trusted in the keystore.
This ans does not make sense so its false.

Please clarify.
Thanks Walter

[scott irwin]

Now I've just started my studies, but here's my security understanding.....
The only trusted classes, by default, are those loaded by the VM�s primordial class loader (bootclass loader) and the extension class loader. Any class loaded by the application class loader (class path) is subject to the JDK 1.2 security framework.
That framework provides for the ability to assign permissions to code (local or remote) associated with different certificates and locations. A notion of domains is created at runtime by the VM. Each domain conforms to a specific configured permission set. All classes placed into a domain, by the VM, enjoy the same permission set of that domain. A domain permission set can range from full access, to the applet sandbox.
Security Policies drive the security framework and are configured using the Policy Tool. A policy can target a class by code base, signature, or both.
When a signature is specified, class must be loaded from a signed jar file. The Policy Tool accepts an alias for a certificate stored in the keyfile. The public key in that certificate is used to verify the signature on the jar file. Here we are assigning permissions to code signed by a private key corresponding to the public key in the key store entry.
Therefore, I argue the following:
-Classes loaded into a browser from the local network are trusted.
False - The class loader inherits the security of the parent class loader, which by default has the applet sandbox permissions.
-Classes loaded into a browser from remote sources are trusted if they are signed.
False - Only half correct. Only jar files can be signed and the corresponding certificate must also be in my keystore as trusted. Just because you are signed, doesn�t mean I trust you.
-Classes loaded into a browser from remote sources are trusted if they are in a signed jarfile.
False � Now we have a jar file, but we still need the corresponding certificate in my key file.
-Classes loaded from a jarfile on a remote source can sometimes be trusted even if the jarfile is unsigned.
True � You can specify a codebase value of the remote source as trusted. You can leave the signer blank. So, any code loaded from that source can have a security policy set to wide open if you want!
-Classes loaded from a signed jarfile are trusted if the public key associated with the jarfile's signature is marked as trusted in the keystore.
True � Where is this wrong? You sign a jar file, it contains a certificate and a public key. The keystore contains public keys which have security policies. If the public key in the signed jar file has a corresponding public key in the key store, those classes get the associated security policy.
Scott

[This message has been edited by scott irwin (edited May 15, 2001).]

[Mark Donaghue]

Hi Scott,
Regarding thislast statement,
"The keystore contains public keys which have security policies."
I did not know about this. I thought that only classes are granted permissions in the policy file. However, my understanding on security is incomplete, so I could easily be wrong.
Regards,
Mark

[scott irwin]

The keystore doesn't have the policies, but the priviate keys are associated with security policies stored in policy files.
Hey, if Sun can be ambiguous so can I

[Vivek Viswanathan]

Hi
Could some one gimme address for sites that have sample tests for the, SCEA Part I.
Thanx

Vivek

[Walter Vetrivel]

http://www.certificationguru.com/javaarchitectresources.html

[scott irwin]

So does anybody know why that last question is wrong? Is there some semantic thing I have missed?
Scott

[Mark Donaghue]

Hi Scott,
If there is a class X in a signed jarfile, but there is no code entry for it in the policy file currently in effect, then what permissions does it have? The "keystore" entry doesn't specify permissions.
Regards,
Mark

[scott irwin]

Mark,
My security book is at home, but you have not said you trusted that certificate. Just because I sign something, doesn't mean I get any extra permissions (would you trust me!) So the class would pick up the default security permissions based on your context (running applet or application). You can also write your own security manager which can play in this game.
I started to read the security book and then decided I need a Java Certification break (2-3 months ago). So I need to revisit Java 2 Security.
Scott

[Mark Donaghue]

Scott,
If it's in the keystore, doesn't that mean the certificate is trusted? I think that a class must still be granted specific permission do an operation that would normally be restricted. If it's local code, then all bets are off anyway (unless a security manager was specified when the app was started).
Regards,
Mark

[scott irwin]

Mark,
Before you just stated that it was signed, but didn't say the private key was in the keystore.
The keystore is just a little repository of keys and certificates. Java 2 security is a two step process. First you import the certificate using the keytool and then you must use the policytool to define the permissions.
So in the case you present, I've heard of you, but never said you could do anything (I know my neighbor but he doesn't have keys to my house.)
Any SCEA can jump here and clarify or correct me if I'm wrong.
I think I just answered my own question! The last question is wrong because it is a two step process. Just because you are in the keystore doesn't give you any permissions. You also have to have a policy associated with the key. So I can now change my answer to False to the last question. Thanks Mark!
Scott

[This message has been edited by scott irwin (edited May 16, 2001).]

[Mark Donaghue]

Scott,
This is a very useful conversation, because it's helping me clear up some fuzzy concepts I've had about security.
Heres what I think is happening: the keystore contains certificates, each of which which contains the public key of a trusted source, and which is named by an alias. These are certificates imported into keystore to run someone else's code.
Keytool can also be used to create your own public/private key pairs. Presumably, the private key would used to sign your own jar files, the public key what you would export to others who use your code.
When a java class executes, the security manager checks in the policy file to see if that codebase has permission to do what it wants to do. Also, if the grant entry has a "signed by" entry, then the security manager uses the "signed by" entry to look up the public certificate in the keystore (matching on alias). If it's there, then it's from a trusted source. The keystore to check is named in the keystore entry of the relevant policy file.
Regards,
Mark

[This message has been edited by Mark Donaghue (edited May 17, 2001).]
[This message has been edited by Mark Donaghue (edited May 17, 2001).]

[scott irwin]

Mark,
Yes, that appears to be the process. There are two approaches to incorporating your policy file into the VM. You can either specify it specifically on the command line
<code>
java -Djava.security.manager -Djava.security.policy=xyz.policy ..
</code>
or add your xyz.policy to the java.security file.
The VM will read in those policy files specified and use the corresponding keystores optionally identified by the policy.
Scott

[Amanda Waite]

I'v not followed the entire thread (even though I started it) but thought you should know that in jdk1.3.x (1.3.1 was released today!!) applets can be granted permisions without the use of a policy file by using RSA signing. See:
http://java.sun.com/products/plugin/1.3/docs/nsobjsigning.html
One of my customers uses it to great success.
Mandy