HydraTest Plan

Service Description

Hydra is a distributed redundant keystore. The CERN twiki has a description and installation instructions. The available test can be found in the glite CVS. There is also a README file in the CVS with testing details.

Features/Scenarios to be tested

These are the tests for the client side glite-eds-* and glite-ssss-* commands and their parameters. There is also a test for the server to check that required services are running. The tests can be run with default parameters, or they can use specific parametes/environment variables as described in README. All tests require at least one voms proxy certificate. The hydra client and server can be installed on the same machine for the tests. If they are not, hydra-server-test.sh should be run on the server, the other tests on the client.

'Service ping test' (implemented)
This test checks that all required services are configured and running on the server.

Normal workflow - correct input
This service has no input. The test prints output for each succesful subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out which service is not running or configured properly.

Pass/Fail Criteria
This test should pass if all required services are running, otherwise it should fail

'SSSS-tools test' (implemented)
This test checks the glite-ssss-* tools that are a prerequisite for hydra to work.

Normal workflow - correct input
This test can optionally test that man pages are found if MAN_PAGE_CHECK is set (dafault). This test takes no input. The test prints the success of each individual subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out which aspect of the commands do not work, and aborts further tests.

Pass/Fail Criteria
This test should pass if all tests pass and glite-ssss-* commands behve as described. Otherwise the test fails.

'Key registration test' (implemented)
This test depends on previous tests. The test tries to register and unregister keys in the hydra keystore.

Normal workflow - correct input
This test can optionally test that man pages are found if MAN_PAGE_CHECK is set (dafault). This test takes no input. The test prints the success of each individual subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out what failed in the key registration process and aborts further tests.

Pass/Fail Criteria
This test should pass if all tests pass and keys can be registered and unregistered. Otherwise the test fails.

'Crypt test' (implemented)
This test depends on previous tests. The test tries to en-/decrypt a file using the keys in the hydra keystore.

Normal workflow - correct input
This test can optionally test that man pages are found if MAN_PAGE_CHECK is set (dafault). This test takes no input. The test prints the success of each individual subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out what failed during en-/decrption and aborts further tests.

Pass/Fail Criteria
This test should pass if all tests pass and files can be en-/decrypted succesfully. Otherwise the test fails.

'ACL test' (implemented)
This test depends on previous tests. The test tries to change the ACL of keys in the keystore.

Normal workflow - correct input
This test can optionally test that man pages are found if MAN_PAGE_CHECK is set (dafault). This test can use two proxy certificates to verify that the ACL is enforced. The test prints the success of each individual subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out what failed during either modifying the ACL permissions, or accessing keys, and aborts further tests.

Pass/Fail Criteria
This test should pass if all tests pass and the ACLs can be set. If two proxy certificates are available, the ACL permission enforcing checks need to pass. In only one proxy certificate is available, the ACL permission enforcing test are not run.

'Chmod test' (implemented)
This test depends on previous tests. The test tries to change the user), =group and other permissions of keys in the keystore.

Normal workflow - correct input
This test can optionally test that man pages are found if MAN_PAGE_CHECK is set (dafault). This test can use two proxy certificates to verify that the chmod options are enforced. The test prints the success of each individual subtest, and a final success confirmation.

Error workflow - erroneous input
If a subtest fails, the test prints out what failed during either modifying the chmod permissions, or accessing keys, and aborts further tests.

Pass/Fail Criteria
This test should pass if all tests pass and the chmod permissions can be set. If two proxy certificates are available, the chmod permission enforcing checks need to pass. In only one proxy certificate is available, the chmod permission enforcing test are not run.

Features not to be tested

'File storage and retrieval test'

The storage and retrieval of encypted files to/from grid storage elements should be tested. There are bugs in the current hydra commands and their gfal usage. These are being fixed, but until then this feature cannot be tested. The main problem is that the primary user group never use hydra file storage, only retrieval.

Stress testing

There is a simple stress/performance testing script included. It spawns multiple threads to register/unregister keys, and reports how many keys were handled / second

Hydra security testing

As security is a very critical part of the Hydra service, a security test should be done to both the client side and the server side.

Hydra server security testing

The hydra server is more security-critical than the client. The server can be hosted by an unknown party, and it contains (parts of) encryption keys which can give access to classified data. The server is written in the Java language, which makes it resistant to some attacks (e.g. buffer overflow). The server can however be vulnerable to many other types of attacks, and here I try to identify the most critical parts of the software, and what should be checked.

Installation

  • Tomcat is configured properly to use correct host certificate, any cerftificates + keys that are copied have the correct permissions on the filesystem.
  • Access to created databases is given only to specified users
  • Any files which contain passwords have restrictive filesystem permissions
  • No passwords are left in installation (or other) logs

Server

  • Client input is always verified
    • In every place, client input must be assumed to be malicious
    • All database inputs need to be sanitized
    • Resulting data from database queries should be verified as far as possible
    • Client certificate needs to be valid (CA, VO, expiry)
  • In all operations the user is only authorized to access (/remove/modfify) what the ACL and permissions allow him/her to
  • Multiple commands are handled in a way so that each command is authorized separately
  • The database connection is handled securely if database is on another machine
    • No cleartext authentication or key(part) exchange (REQUIRED?)

Hydra client security testing

The hydra client is run by the user so it is not as vulnerable as the server. The client handles encryption keys however, so their correct usage should be confirmed.

Client

  • Key generation is done with specified ciphers and keylengths
  • After key usage the memory area where the keys were is blanked or randomized.
  • The client checks that the server has a valid certificate which matches the hostname

-- KalleHapponen - 04 Aug 2008

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r8 - 2009-01-22 - KalleHapponen
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback