# Presentation: 623713

## Security Evaluation of Grid Environments

- Barton P. Miller
- bart@cs.wisc.edu
- Computer Sciences Department
- University of Wisconsin
- Madison, Wisconsin 53706
- USA

## A Project to Evaluate Security

- Designing for security is important, but not the whole story.
- Security evaluation should include
- Both white hat and black hat efforts,
- Both insider and outsider studies.
- Based on these considerations, we are starting a pilot effort to evaluate the security of Condor
- But first, a short story . . .

## Condor Job Structure

- Submitting Host

- Shadow Process

- Execution Host

- User Job

## Condor Job Structure

- Submitting Host

- Shadow Process

- Execution Host

- Evil
- User Job

- system calls

## Condor Job Structure

- Submitting Host

- Execution Host

- Lurker
- Process

## Condor Job Structure

- Submitting Host

- Shadow Process

- Execution Host

- Innocent
- User Job

- Lurker
- Process

## Condor Job Structure

- Submitting Host

- Shadow Process

- Execution Host

- Innocent
- User Job

- Lurker
- Process

- attach

## Condor Job Structure

- Submitting Host

- Shadow Process

- Execution Host

- Innocent
- User Job

- Control remote
- system calls

- Lurker
- Process

**rm -rf ***

## A Pilot Study

- MIST: Middleware Intrusion & Security Testing Center
- Evaluate the Condor software stack.
- Architectural analysis.
- Resource analysis.
- Establish trust boundaries.
- Vulnerability assessment.
- Design feedback.

## Architecture

## Condor Daemon Layout

**Central Manager**

**User**

**Problem Solver**
- (DAGMan)(Master-Worker)

**startd**

**schedd**

**Shadow**

**Executing Host**

**startd**

**schedd**

**Starter**

**User Job**

**Collector**

**Negotiator**

- 1. Job Description File

- 2. Job ClassAd

- 3. Job ClassAd

- 1. Machine ClassAd

- 5. Report Match

- 5. Report Match

- 6. Claim Host

- 7. fork Shadow

- 8. Establish Communication Path

- 8. fork User Job

- 4. Negotiation Cycle

- 7. fork
- Starter

## Standard Universe Execution

**Shadow**

**I/O Server**

**OS Kernel**

**Executing Host**

**Starter**

**OS Kernel**

**User Job**
**Condor C Library**

- 8. Return

- 1. System Call

- 4. System Call

- 5. Return

- 3. System Call via
- Secure RPC

- 6. Return via
- Secure RP

- 2. System Call

- 7. Return

## Dynamic Port Forwarding

**Firewall / Gateway**

**DPF Server**

**NAT**

**Pass-Through**

**Private Network**

**Public Network**

**External****Condor Host**
- (ipC:portD)

**Internal****Condor Host**
- (ipX:portY)

**Central Manager**

- Condor Traffic

- DPF-ModifiedCondor Traffic

- DPF Control Traffic

- 1. bind ipX:portY

- 2. set ruleipA:portB -> ipX:portY

- 3. ok

- 4. bound ipA:portB

- 5. Machine ClassAdipA:portB

- 6. Job ClassAd

- 7. Notify of matchwith ipA:portB

- 7. Notify of matchwith ipC:portD

- 8. Claim resource andinitiate connection

## Generic Connection Brokering

**Private Network A**

**Public Network**

**Private Network B**

**Internal****Condor Host B**
- (ipX:portY)

**Internal****Condor Host A**
- (ipV:portW)

**Central Manager**
- (ipE:portF)

**GCB Server B**
- (ipB)

**GCB Server A**
- (ipA)

- Condor Traffic

- GCB-ModifiedCondor Traffic

- GCB Control Traffic

- 1. bind ipX:portYand maintain TCPconnection

- 2. bound ipB:portD

- 3. Job ClassAdipA:portC

- Note: Communications 1, 2, 4, 5, 6, 7, and 8 also occur between Internal Condor Host A, GCB Server A, and the Central Manager in a symmetric fashion, allowing ipV to bind to its GCB agent and the Central Manager to notify ipV of a match.  These communications are omitted for the sake of economy.

- 4. connect to ipB:portD

- 5. use PASSIVE mode

- 6. CONTACT ipE:portF

- 7. initiate connection

- 8. notify of match with ipA:portC

- 3. Machine ClassAdipB:portD

- 9. connect to ipB:portD

- 10. use ACTIVE modeipB:portR1

- 10. CONTACT
- ipB:portR2

- 11. initiateconnection

- 11. initiate connection

- portR1

- portR2

## Insider Vulnerability Analysis

- Component analysis:
- Static analysis tools: buffer overruns, API analysis, etc.
- Structural analyses
- Configuration parameters and files
- Inter-Component analysis:
- Internal protocol structure
- Trust relationships and delegation
- Interactions with firewalls

## Outsider Vulnerability Assessment

- Commodity components:
- Operating system
- Scheduling software
- Authentication and certificate facilities
- File systems
- Firewalls and routes
- Public Grid protocols and interfaces
- Leverage sources of known vulnerabilities, such as CERT.

## Feedback

- Code and configuration suggestions and fixes.
- Try to codify techniques into tools.
- Deployment of additional tools, such as network-based and host-based intrusion detection systems

## A Key Part of any Solution:A Grid Security Evaluation Center

- Use a similar methodology on a wider selection of Grid software and facilities.
- Joint effort of evaluation team and development teams.
- Develop common tools to streamline the process.
- Develop guidelines as to design, deployment, configuration, checking.