End-to-end Security and Condor

1. End-to-end Security and Condor Condor Week 2008

2. Condor Week 2008 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. Condor Week 2008 Outline • The Problem • History of Condor • Stakeholders • Framework mechanisms • Related work • Summary and conclusions

4. General Trust Model ... ... Service 2 Service k+1 Service n Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data ~ ~ Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data ... ... Service 1 Service k Service n-1 Proxy Read/Write DB / SE

5. The Problem: Altered Task, Input, or Results ... ... Service 2 Service k+1 Service n Proxy Exe1+args1 Data Proxy Exe1+args1 Data Proxy Exe+args Data ~ ~ Proxy Exe+args Data Proxy Exe1+args1 Data Proxy Exe+args Data Proxy Exe1+args1 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 k+1 Service n Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data ~ ~ Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args 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 Exe1+args1

7. Condor Week 2008 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. Condor Week 2008 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 negotiator collector 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 negotiator collector 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 negotiator collector 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 negotiator collector 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. Condor Week 2008 Today:Multiple domain distributed batch computing

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

15. Condor Week 2008 Stakeholders: Submitters • “Just want to get work done, don’t 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. • Don’t have any way of expressing policy.

16. Condor Week 2008 Stakeholders: Schedulers • Successful w/ goodput. • Don’t want to waste time. • Security can be expensive in CPU time. • Don’t advertise resources that don’t exist. • Don’t need to change job payloads. • Don’t want to get attacked.

17. Condor Week 2008 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. • Don’t want to get attacked. • Need audit capability if they do.

18. Condor Week 2008 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 don’t have access to information about tasks. • Can’t change authentication/authorization very much. • Need audit capability.

19. Condor Week 2008 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 k+1 Service n Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data ~ ~ Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data Proxy Exe+args Data ... ... Service 1 Service k Service n-1 Proxy Read/Write DB / SE Endpoints handle integrity, confidentiality. Intermediaries just responsible for availability.

21. Sign executable+args Proxy X = Proxy with rule “Execute iff hash(Exe+args)==myhash” ... ... Service 2 Service k+1 Service n Proxy X Exe'+args' Data Proxy X Exe'+args' Data Proxy X Exe+args Data ~ ~ Proxy X Exe+args Data Proxy X Exe'+args' Data Proxy X Exe+args 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 k+1 Service n ProxyY Exe+args Data+data1 ProxyY Exe+args Data+data1 ProxyY Exe+args Data ~ ~ ProxyY Exe+args Data ProxyY Exe+args Data+data1 ProxyY Exe+args 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. [ owner = “ian” executable = “a.out” input = “file1.txt” arguments = “-safe” ... executable_hash = “de1a...” input_hash = “be5ed23a0...” ... cad_sig = “long opaque string” ] 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.

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 -> 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 k+1 Service n ProxyZ Exe+args Data ProxyZ Exe+args Data ProxyZ Exe+args Data ~ ~ ProxyZ Exe+args Data ProxyZ Exe+args Data ProxyZ Exe+args Data ProxyW Exe+args 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 Exe1+args1

29. Condor Week 2008 Outline • The Problem • History of Condor • Stakeholders • Framework mechanisms • Related work • Secure message board • … • Summary and conclusions

30. Condor Week 2008 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. Condor Week 2008 Secure Message Board Good security design results in new possibilities: things you can do that you couldn’t 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. Condor Week 2008

33. Condor Week 2008 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@cs.wisc.edu