Assignment 4 Clarifications!!!

 

Your policy file must enforce that all client code be signed by known parties. You should at least be able to execute code signed by the "CS415 tester". To be able to verify the digital signature of the CS415 tester, your server needs to know the public key that corresponds to the private key that the CS415 tester uses to sign his code. This public key is encapsulated in the (self-signed) certificate:

-----BEGIN CERTIFICATE-----

MIIDUDCCAw4CBDoZ3hAwCwYHKoZIzjgEAwUAMIGNMQswCQYDVQQGEwJOWTEQMA4GA1UECBMHTmV3

WW9yazEPMA0GA1UEBxMGSXRoYWNhMRswGQYDVQQKExJDb3JuZWxsIFVuaXZlcnNpdHkxJzAlBgNV

BAsTHkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZTEVMBMGA1UEAxMMY3M0MTUgdGVzdGVy

MB4XDTAwMTEyMTAyMjkzNloXDTAwMTIyMTAyMjkzNlowgY0xCzAJBgNVBAYTAk5ZMRAwDgYDVQQI

EwdOZXdZb3JrMQ8wDQYDVQQHEwZJdGhhY2ExGzAZBgNVBAoTEkNvcm5lbGwgVW5pdmVyc2l0eTEn

MCUGA1UECxMeRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlMRUwEwYDVQQDEwxjczQxNSB0

ZXN0ZXIwggG3MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/

gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfG

G/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKS

uYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEH

EIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+

qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhAACgYB0dXoHrY1YHmOJ2EOiHkI3GGVd5/u1

pHq846RasCHVYJC9y6hu2+elBirbD+vdq1RL/a1Zp+gbS5fGGSV+/N1oCQh5GxB7fcVJOjXYbABA

tMXQY8Icc+YJW+sEpgBLYFjrepJ3IK4d7B7JpicSeNiv6BmBaZ2VK7n3K1hIQupJQDALBgcqhkjO

OAQDBQADLwAwLAIUYFRJ/1f6+ObagIHNYuT2LbtaRxoCFD085QSfvJ3Mjx/7ZSfrY90NlFNl

-----END CERTIFICATE-----

 

The human-readable version of this certificate is as follows:

Owner: CN=cs415 tester, OU=Department of Computer Science, O=Cornell University, L=Ithaca, ST=NewYork, C=NY

Issuer: CN=cs415 tester, OU=Department of Computer Science, O=Cornell University, L=Ithaca, ST=NewYork, C=NY

Serial number: 3a19de10

Valid from: Mon Nov 20 21:29:36 EST 2000 until: Wed Dec 20 21:29:36 EST 2000

Certificate fingerprints:

       MD5:  05:68:92:E1:41:7D:47:DD:13:BD:7D:5B:1E:E0:CD:BC

       SHA1: 41:29:0A:55:9C:78:B9:63:7E:46:F7:D3:6F:64:65:99:A5:50:FA:F6

You should import the certificate into your server's key store, a database that contains the certificates of parties that are known to the server.

·         A useful mechanism is the doPrivileged() method in class java.security.AccessController(). This mechanism extends the set of permissions available to a thread to the permissions associated with the current protection domain. This allows you to write small pieces of trusted code. For example, you may not want to give client code access to arbitrary files. Instead, you can write some trusted code that accesses particular files only after it has made some security checks. This way, clients can only gain extra privileges in a controlled manner. You should compare this mechanism to Unix's setuid mechanism.

Securing the storage server

You must secure the storage server by adding capabilities and by making sure that client code that runs on the server cannot do great damage to the server. To do this, you should

·         Arrange for each client to share a secret key with the server. Assume that a unique number identifies each user. The client must store its key in a file name keys.client.n, which must be stored in the user's home directory; n is the client's number. So file keys.client.34 would contain the keys for client 34. This file contains one line with the client's secret key (a number). The server stores the keys it shares with clients in a file keys.server, which is stored in the server's home directory. This file contains one line per client. Each line contains the client's number, a space, and the secret key that the client shares with the server.

·         Assume that when a process creates a Credentials object, it will pass the user's id as an argument to the constructor. ("The user" is the user on whose behalf the process is running.)

·         Make sure that the server will only handle requests from known clients (clients listed in keys.server).

·         Make sure that client code downloaded onto the server can access those storage units that the code can present capabilities for, but no others.

·         Make sure that client code downloaded onto the server cannot corrupt or kill the server by writing to files or variables without appropriate permissions cannot leak information to the client that the client should not have access to, etc. Write a sensible policy file for the storage server and store it in the top-level directory of your storage server code. The file must be called policy.server. Your policy file should grant unrestricted to the server itself, but should give restricted permissions to client code. In particular, you must enforce that all client code be signed. The public keys of known parties must be stored in file keystore.server, which must be stored in the top-level directory of you storage server code. You must protect you key store with password cs415test.