End-to-end Security and Condor

1
End-to-end Security and Condor
2
End-to-End Security and Condor

• When Condor was first designed, a single
  administrative domain was all that was required
  all Condor daemons were installed and configured
  by the same group.
• Practical concerns have led to the adoption of
  mechanisms that violate this assumption.
• Goal Develop framework balancing usability
  (w.r.t. both end-users and administrators) with
  security in the context of multiple
  administrative domains.

3
Outline

• The Problem
• History of Condor
• Stakeholders
• Framework mechanisms
• Related work
• Summary and conclusions

4
General Trust Model
...
...
Service 2
Service n
Service k1
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data


Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
...
...
Service 1
Service k
Service n-1
Proxy Read/Write
DB / SE
5
The Problem Altered Task, Input, or Results
...
...
Service 2
Service n
Service k1
Proxy Exe1args1 Data
Proxy Exe1args1 Data
Proxy Exeargs Data


Proxy Exeargs Data
Proxy Exe1args1 Data
Proxy Exeargs Data
Proxy Exe1args1 Data
...
...
Service 1
Service k
Service n-1
DB / SE
Arbitrary code is run in user's name
6
The Problem Stolen Credentials
...
...
Service 2
Service n
Service k1
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data


Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
...
...
Service 1
Service k
Service n-1
Proxy Read/Write
Proxy
DB / SE
Unauthorized access to user's information
systems (possibly corrupting them)?
Proxy Read1/Write1
Proxy Exe1args1
7
Design Principles

• End-to-end Principle Saltzer, Reed Clark, 1985
• The function in question can completely and
  correctly be implemented only with the knowledge
  and help of the application standing at the end
  points of the communication system. Therefore,
  providing that questioned function as a feature
  of the communication system itself is not
  possible.
• Principle of Least Privilege Saltzer
  Schroeder, 1975
• Least privilege Every program and every user of
  the system should operate using the least set of
  privileges necessary to complete the job.

8
Outline

• The Problem
• History of Condor
• Multiple domain distributed batch computing
  infrastructure
• v. Grid
• Stakeholders
• Framework mechanisms
• Related work
• Summary and conclusions

9
Privileges - Root Install
Central Manager
Real UIDs
4. Negotiation Cycle
root
collector
negotiator
condor
user
1. Machine ClassAd
nobody
Execute Host
5. Report Match
Submit Host
startd
4.Negotiation Cycle 5. Report Match
User
3. Job ClassAd
startd
7. fork Starter
schedd
6. Claim Host
schedd
1. Job Description File
starter
2. Job ClassAd
7. fork Shadow
8. Establish Communication Path
submit
9. Set policy and fork User Job
shadow
User Job
10
Condor History Origins
Central Manager
Administrative Domains
4. Negotiation Cycle
home
collector
negotiator
1. Machine ClassAd
Execute Host
5. Report Match
Submit Host
startd
4.Negotiation Cycle 5. Report Match
User
3. Job ClassAd
startd
7. fork Starter
schedd
6. Claim Host
schedd
1. Job Description File
starter
2. Job ClassAd
7. fork Shadow
8. Establish Communication Path
submit
9. Set policy and fork User Job
shadow
User Job
11
Condor History Flocking
Central Manager
Real UIDs
4. Negotiation Cycle
home
collector
negotiator
away
1. Machine ClassAd
Execute Host
5. Report Match
Submit Host
startd
4.Negotiation Cycle 5. Report Match
User
3. Job ClassAd
startd
7. fork Starter
schedd
6. Claim Host
schedd
1. Job Description File
starter
2. Job ClassAd
7. fork Shadow
8. Establish Communication Path
submit
9. Set policy and fork User Job
shadow
User Job
12
Condor History Condor-G, C
Central Manager
Real UIDs
4. Negotiation Cycle
home
collector
negotiator
away
1. Machine ClassAd
Scheduler
5. Report Match
Submit Host
4.Negotiation Cycle 5. Report Match
User
3. Job ClassAd
startd
schedd
6. Claim Resource
schedd
1. Job Description File
2. Job ClassAd
8. Transfer Job
7. fork GAHP
submit
GAHP
13
TodayMultiple domain distributed batch computing
14
Outline

• The Problem
• History of Condor
• Stakeholders
• Submitters
• Schedulers
• Execution hosts
• Storage elements
• Framework mechanisms
• Related work
• Summary and conclusions

15
Stakeholders Submitters

• Just want to get work done, dont care about
  anything else.
• Actually, do care about reproducibility and
  accuracy of results.
• May care about confidentiality of tasks and data.
• Want to know the following about their jobs
  what, when, where, who, why.
• Dont have any way of expressing policy.

16
Stakeholders Schedulers

• Successful w/ goodput.
• Dont want to waste time.
• Security can be expensive in CPU time.
• Dont advertise resources that dont exist.
• Dont need to change job payloads.
• Dont want to get attacked.

17
Stakeholders Execute Hosts

• Have a trust relationship with users users trust
  them to execute tasks accurately and return
  correct results
• Successful when many users successfully run many
  jobs (but only the real users real jobs).
• Need to perform authorization based on user
  credentials must trust users, too.
• Dont want to get attacked.
• Need audit capability if they do.

18
Stakeholders File Servers

• Have a trust relationship with users, not with
  execute hosts or schedulers users trust them to
  enforce access control policies.
• Responsible for enforcing access control policy,
  but ACLs dont have access to information about
  tasks.
• Cant change authentication/authorization very
  much.
• Need audit capability.

19
Outline

• The Problem
• History of Condor
• Stakeholders
• Framework mechanisms
• Signed ClassAds
• Task-specific proxy certificates
• Service-specific proxy certificates
• Policy expressions
• Related work
• Summary and conclusions

20
Untrusted services?
We need to trust the end-points, we have no choice
...
...
Service 2
Service n
Service k1
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data


Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
Proxy Exeargs Data
...
...
Service 1
Service k
Service n-1
Proxy Read/Write
DB / SE
Endpoints handle integrity, confidentiality.
Intermediaries just responsible for
availability.
21
Sign executableargs
Proxy X Proxy with rule Execute iff
hash(Exeargs)myhash
...
...
Service 2
Service n
Service k1
Proxy X Exe'args' Data
Proxy X Exe'args' Data
Proxy X Exeargs Data


Proxy X Exeargs Data
Proxy X Exe'args' Data
Proxy X Exeargs Data
...
...
Service 1
Service k
Service n-1
End point checks signature before execution
DB / SE
Requirements WN must be able to determine
integrity of executables. User specifies policy
Worker node interprets it. WN must be able to
associate task with proxy.
22
Sign data
ProxyY Proxy with rule Stage data iff
hash(data)myhash
...
...
Service 2
Service n
Service k1
ProxyY Exeargs Datadata1
ProxyY Exeargs Datadata1
ProxyY Exeargs Data


ProxyY Exeargs Data
ProxyY Exeargs Datadata1
ProxyY Exeargs Data
...
...
Service 1
Service k
Service n-1
End point checks signature before staging
data Since without data the job could fail, it
should not run the job either
DB / SE
Requirements WN must be able to determine
integrity of data.
23
Integrity Signed ClassAds

• WN must be able to verify the integrity of
  executables, arguments, and input data. User
  must be able to verify the integrity of results.
• WN's check signatures on executables, arguments
  and input, and sign output data (results). User
  can verify the signature on the results, and
  verify whether the WN was consistent with policy.
• The task's signed ClassAd specifies executables,
  arguments, and input data external files are
  included through cryptographic hashes.
  Completed task ClassAds are signed by WNs before
  output data is returned to the client output
  data file hashes are included.

Requirement Solution Implementation
24
Integrity Signed ClassAds

• WN must be able to verify the integrity of
  executables, arguments, and input data. User
  must be able to verify the integrity of results.
• WN's check signatures on executables, arguments
  and input, and sign output data (results). User
  can verify the signature on the results, and
  verify whether the WN was consistent with policy.
• The task's signed ClassAd specifies executables,
  arguments, and input data external files are
  included through cryptographic hashes.
  Completed task ClassAds are signed by WNs before
  output data is returned to the client output
  data file hashes are included.

• owner ian
• executable a.out
• input file1.txt
• arguments -safe
• ...
• executable_hash de1a...
• input_hash be5ed23a0...
• ...
• cad_sig long opaque string

25
User Specified Policies

• Users must be able to specify policies describing
  appropriate uses of their tasks and credentials.
  Worker nodes and resources must be able to
  interpret and enforce policies.
• Users specify policies such as acceptable WN
  trust roots and signs executables, arguments and
  input data. Policy enforcement is performed by
  trusted endpoints and policy aware resources.
• Users specify policy in the ClassAd language with
  additional primitives. ClassAd policy
  expressions are evaluated by endpoints and
  resources in addition to local access control
  settings. (ACLs capabilities)?

Hash of public key x hPx execute_aae
exec_ca(hPe)? access_aae exec_ca(hPe)
resource_ca(hPr)?
26
Task-specific proxies

• Unique executable, arguments, input data -gt
  unique proxy. Intermediaries don't need to
  understand, interpret or enforce policy.
• Each task has a unique proxy certificate issued
  by the submitting user's proxy. Intermediaries
  are only assumed to provide availability.
• An additional proxy is generated by the user for
  each task containing the policies and signature.
  Policy and signatures are included in proxy
  certificates as an X509.v3 attribute which can be
  ignored by intermediaries.

27
Service-specific proxies

• When a WN authenticates with a service on behalf
  of a user, the service must be able to
  authenticate both the user and the WN to enforce
  the user's policy.
• Proxy delegation includes the additional step of
  including a signature performed by the WN on the
  delegation chain.
• The resource enforces policy by verifying that
  the signing WN is consistent with user-specified
  policy.

28
Authenticating the WN too
ProxyZ Proxy with rule Allow access to my info
systems only if signed by trusted WN
ProxyW ProxyZ signed with the WN host cert (or
equivalent)?
...
...
Service 2
Service n
Service k1
ProxyZ Exeargs Data
ProxyZ Exeargs Data
ProxyZ Exeargs Data


ProxyZ Exeargs Data
ProxyZ Exeargs Data
ProxyZ Exeargs Data
ProxyW Exeargs Data
...
...
Service 1
Service k
Service n-1
ProxyW Read/Write
Information system checks for signature from
trusted WN. An untrusted resource cannotadd it.
ProxyZ
DB / SE
ProxyZ Read1/Write1
Requirements Proxy and WN authenticate to
services.
ProxyZ Exe1args1
29
Outline

• The Problem
• History of Condor
• Stakeholders
• Framework mechanisms
• Related work
• Secure message board
• Summary and conclusions

30
Related Work

• Privsep Glide-ins
• Third party information (VOMS, Shibboleth,
  SPRUCE)
• Use case Message service
• Authorization services collaboration
• Authentication methods
• Encryption and integrity methods (AES, SHA-1,
  SHA-256)

31
Secure Message Board

• Good security design results in new
  possibilities things you can do that you
  couldnt do without the security features. Ex
• Components can publish information to the
  condor_collector using condor_advertize.
• Igor uses this mechanism to exchange information
  from VO frontends to glide-in factories.
• Currently, only authorization provided by CEDAR
  provides access control anyone (who can write
  something) can write anything.
• So, Igor can only have one VO frontend per
  collector.
• Signed ClassAds to the rescue.

32
(No Transcript)
33
Summary and Conclusion

• As systems evolve, security mechanisms need to
  evolve along with them.
• Developed framework balancing usability (w.r.t.
  both end-users and administrators) with security
  in the context of multiple administrative
  domains.
• Met design goals, additional new usage is being
  discovered as well.

34
Questions?

• For more information, contact
• Ian Alderman
• alderman_at_cs.wisc.edu