End-to-end Security and Condor Ian D Alderman Computer

End-to-end Security and Condor Ian D. Alderman Computer Sciences Department University of Wisconsin-Madison alderman@cs. wisc. edu http: //www. cs. wisc. edu/condor 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. Condor Week 2008 www. cs. wisc. edu/condor 2

Outline › › › The Problem History of Condor Stakeholders Framework mechanisms Related work Summary and conclusions Condor Week 2008 www. cs. wisc. edu/condor 3

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

The Problem: Altered Task, Input, or Results Service k+1 Proxy Exe 1+args 1 Data Proxy Exe+args Data Service 1 ~ Proxy Exe+args Data . . . Service k ~ Service 2 . . . Service n Proxy Exe 1+args 1 Data . . . Proxy Exe 1+args 1 Data Service n-1 Arbitrary code is run in user's name DB / SE

The Problem: Stolen Credentials Service 1 . . . Service k+1 Proxy Exe+args Data ~ Service 2 Proxy Exe+args Data Service k Service n Proxy Exe+args Data Service n-1 . . . Proxy Exe+args Data Proxy Read/Write Proxy Unauthorized access to user's information systems (possibly corrupting them) Proxy Read 1/Write 1 Proxy Exe 1+args 1 DB / SE

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. Condor Week 2008 www. cs. wisc. edu/condor 7

Outline › The Problem › History of Condor “Multiple domain distributed batch computing infrastructure” › › v. “Grid” Stakeholders Framework mechanisms Related work Summary and conclusions Condor Week 2008 www. cs. wisc. edu/condor 8

Privileges - Root Install Central Manager Real UIDs 4. Negotiation Cycle root negotiator condor collector user 1. Machine Class. Ad nobody Execute Host 5. Report Match Submit Host 4. Negotiation Cycle 5. Report Match startd 3. Job Class. Ad User 7. fork Starter startd schedd 6. Claim Host 1. Job Description File 2. Job Class. Ad submit schedd 7. fork Shadow starter 8. Establish Communication Path 9. Set policy and fork User Job

Condor History: Origins Central Manager Administrative Domains 4. Negotiation Cycle home negotiator collector 1. Machine Class. Ad Execute Host 5. Report Match Submit Host 4. Negotiation Cycle 5. Report Match startd 3. Job Class. Ad User 7. fork Starter startd schedd 6. Claim Host 1. Job Description File 2. Job Class. Ad submit schedd 7. fork Shadow starter 8. Establish Communication Path 9. Set policy and fork User Job

Condor History: Flocking Central Manager Real UIDs 4. Negotiation Cycle home negotiator away collector 1. Machine Class. Ad Execute Host 5. Report Match Submit Host 4. Negotiation Cycle 5. Report Match startd 3. Job Class. Ad User 7. fork Starter startd schedd 6. Claim Host 1. Job Description File 2. Job Class. Ad submit schedd 7. fork Shadow starter 8. Establish Communication Path 9. Set policy and fork User Job

Condor History: Condor-G, C Central Manager Real UIDs 4. Negotiation Cycle home negotiator away collector 1. Machine Class. Ad Scheduler 5. Report Match Submit Host 4. Negotiation Cycle 5. Report Match 3. Job Class. Ad User startd schedd 6. Claim Resource 1. Job Description File 2. Job Class. Ad submit schedd 7. fork GAHP 8. Transfer Job

Today: Multiple domain distributed batch computing Condor Week 2008 13

Outline › The Problem › History of Condor › Stakeholders ∘ Submitters ∘ Schedulers ∘ Execution hosts ∘ Storage elements › Framework mechanisms › Related work › Summary and conclusions Condor Week 2008 www. cs. wisc. edu/condor 14

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. Condor Week 2008 www. cs. wisc. edu/condor 15

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. Condor Week 2008 www. cs. wisc. edu/condor 16

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. Condor Week 2008 www. cs. wisc. edu/condor 17

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. Condor Week 2008 www. cs. wisc. edu/condor 18

Outline › › The Problem History of Condor Stakeholders Framework mechanisms ∘ Signed Class. Ads ∘ Task-specific proxy certificates ∘ Service-specific proxy certificates ∘ Policy expressions › Related work › Summary and conclusions Condor Week 2008 www. cs. wisc. edu/condor 19

Untrusted services? We need to trust the end-points, we have no choice Service 1 . . . Service k+1 Proxy Exe+args Data Service k . . . ~ Proxy Exe+args Data ~ Service 2 . . . Service n Proxy Exe+args Data Service n-1 . . . Endpoints handle integrity, confidentiality. Intermediaries just responsible for availability. Proxy Exe+args Data Proxy Read/Write DB / SE

Sign executable+args Proxy X = Proxy with rule “Execute iff hash(Exe+args)==myhash” Service k+1 Proxy X Exe'+args' Exe+args Data Proxy X Exe+args Data ~ Proxy X Exe+args Data . . . Service 1 . . . Service k . . . Service n Proxy X Exe'+args' Proxy X Data Exe'+args' Data ~ Service 2 . . . Service n-1 End point checks signature before execution 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. DB / SE

Sign data Proxy. Y = Proxy with rule “Stage data iff hash(data)==myhash” Service k+1 Proxy. Y Exe+args Data+data 1 . . . Service k Proxy. Y Exe+args Data Service 1 ~ Proxy. Y Exe+args Data . . . ~ Service 2 . . . Proxy. Y Exe+args Data+data 1 . . . Service n Proxy. Y Exe+args Data+data 1 Service n-1 End point checks signature before staging data Since without data the job could fail, it should not run the job either Requirements: WN must be able to determine integrity of data. DB / SE

Integrity: Signed Class. Ads › 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 Class. Ad specifies executables, arguments, and input data; external files are “included” through cryptographic hashes. Completed task Class. Ads are signed by WNs before output data is returned to the client; output data file hashes are included. Requirement Solution Implementation

Integrity: Signed Class. Ads › WN must be able to verify the integrity of executables, arguments, and input data. User must be able to verify the integrity of results. [ owner = “ian” executable = “a. out” input = “file 1. txt” arguments = “-safe”. . . executable_hash = “de 1 a. . . ” input_hash = “be 5 ed 23 a 0. . . ”. . . cad_sig = “long opaque string” › 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 Class. Ad specifies executables, arguments, and input data; external files are “included” through cryptographic hashes. Completed task Class. Ads are signed by WNs before output data is returned to the client; output data file hashes are included. ]

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 Class. Ad language with additional primitives. Class. Ad policy expressions are evaluated by endpoints and resources in addition to local access control settings. (ACLs + capabilities) Hash of public key x: h. Px execute_aae = exec_ca(h. Pe) access_aae = exec_ca(h. Pe) && resource_ca(h. Pr)

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 X 509. v 3 attribute which can be ignored by intermediaries. www. cs. wisc. edu/condor

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. www. cs. wisc. edu/condor

Authenticating the WN too Proxy. Z = Proxy with rule “Allow access to my info systems only if signed by trusted WN” Proxy. W = Proxy. Z signed with the WN host cert (or equivalent) Service 1 . . . Service k+1 Proxy. Z Exe+args Data Service k . . . Information system checks for signature from trusted WN. An untrusted resource cannot add it. Requirements: Proxy and WN authenticate to services. ~ Proxy. Z Exe+args Data ~ Service 2 . . . Service n Proxy. Z Exe+args Data Service n-1 . . . Proxy. W Exe+args Data Proxy. W Read/Write Proxy. Z Read 1/Write 1 Proxy. Z Exe 1+args 1 DB / SE

Outline › › › The Problem History of Condor Stakeholders Framework mechanisms Related work ∘ Secure message board ∘ … › Summary and conclusions Condor Week 2008 www. cs. wisc. edu/condor 29

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) Condor Week 2008 www. cs. wisc. edu/condor 30

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 Class. Ads to the rescue. Condor Week 2008 www. cs. wisc. edu/condor 31

Condor Week 2008 32

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

Questions? For more information, contact: Ian Alderman alderman@cs. wisc. edu Condor Week 2008 www. cs. wisc. edu/condor 34