Signed ClassAds and Restricted Delegation

1
Signed ClassAdsand Restricted Delegation
2
(No Transcript)
3
Security Issues in Multiple Administrative
Domains

• Multiple administrative domains arent well
  protected from each other, yet are increasingly
  common Condor-C, Condor-G, flocking
• As cooperation between administrative domains
  increases, so does utilization. Can we take
  advantage of this without also increasing risk?

• Job input and output data
• Execute Machines
• Data unrelated to the job

• Protect

4
Shoulders of Giants

• Principle of least privilege
• Every program and every user of the system
  should operate using the least set of privileges
  necessary to complete the job.
• - Saltzer and Schroeder,
  1975

5
Credential Scope

• Jobs either carry no credentials or the full
  credentials of the submitting user.
• Jobs with credentials can impersonate the
  submitting user without any restriction.
• Intermediaries that handle credentials can lose
  or abuse them, or alter tasks, input, and
  results.

Limit the scope of credentials to what the job
needs and no more.
6
Goals

• Make security assumptions explicit.
• Reduce the number and scope of assumptions that
  must be made about infrastructure w.r.t.
  security.
• Provide end-to-end security options in addition
  to point-to-point security.
• Provide end-to-end cryptographic audit.
• Alter attacker incentives.
• Reduce barriers to increased cooperation and
  utilization.

7
(No Transcript)
8
Framework Overview

• Signed ClassAds
• Digital signature applied to a ClassAd altering
  invalidates the signature.
• Task-specific Proxy Certificates
• GSI proxy certificate with signed ClassAd
  embedded links certificate to a particular task.
• Action Authorization Expressions
• Expressions within the signed ClassAd limit the
  usage of the proxy certificate chain.

9
Participants
U
S
X
R
10
Actions
s
e
a
U
S
X
R
11
Forwarding Action
s
U
S
f
e
a
S
X
R
12
Multiple Administrative Domains
s
U
S
R
f
e
a
S
X
R
13
Authentication
/OBrown CS/CNpavlo
GSI Proxy Certificates Mutual Authentication
s
U
S
f
e
a
S
X
R
/OBrown CS/CNscheduler.cs.brown.edu
/OPenn CS/CNscheduler.cs.penn.edu
/OUMD CS/CNstorage.cs.umd.edu
/OPenn CS/CNex0001.cs.penn.edu
14
Authorization
/OBrown CS/CNpavlo -gt pavlo_at_cs.brown.edu
s
U
S
Recipient checks ACL
f
e
a
S
X
R
15
Problems

• Authorization entirely in the hands of the
  recipients no restrictions can be expressed by
  the submitter.
• Credential too permissive can be used to access
  anything on resources, run any job on execute
  machine.
• Unnecessary reliance on schedulers to preserve
  confidentiality and integrity of credentials.
• No audit trail.

16
Attackers

• Incentive to attack schedulers compromise
  results in full control
• Alter tasks (to attack execute hosts or cause
  them to attack external hosts).
• Access resources using credentials.
• Forge results returned to submitter.

17
Framework Overview

• Signed ClassAds
• Digital signature applied to a ClassAd altering
  invalidates the signature.
• Task-specific Proxy Certificates
• GSI proxy certificate with signed ClassAd
  embedded links certificate to a particular task.
• Action Authorization Expressions
• Expressions within the signed ClassAd limit the
  usage of the proxy certificate chain.

18
Signed ClassAds

• ClassAds with digital signatures.
• Signature made and checked using X.509 keys and
  certificates.
• Altered ClassAds are easily detected.
• External files can be referenced using checksums.
• Explicit association between a task and
  information about its origin and provenance.
• Results can be signed as well receipts.

19
Task-specific Proxy Certificates

• Proxy certificates with embedded signed ClassAds.
• Policy field in proxy certificate contains signed
  ClassAd for the associated job.
• Proxy delegation chain inalterably linked with
  particular job.

20
Action Authorization Expressions

• ClassAd language expressions included in the
  signed ClassAd.
• Can specify conditions on actions that the proxy
  certificate might be used for submit,
  forwarding, execute, and access.
• Permits the submitting user to limit how their
  credentials are used.

21
Mutual Authorization
/OBrown CS/CNpavlo
U/OBrown CS/CNpavlo S/OBrown
CS/CNsche s(U,S)
U/OBrown CS/CNpavlo Sa/OBrown
CS/CNsche Sb/OPenn CS/CNsche f(U, Sa, Sb)
U/OBrown CS/CNpavlo S/OPenn
CS/CNsche X/OPenn CS/CNex0001 e(U, S, X)
U/OBrown CS/CNpavlo X/OPenn
CS/CNex0001 R/OUMD CS/CNstorage a(U, X R)
s
U
S
f
e
a
S
X
R
/OBrown CS/CNscheduler.cs.brown.edu
/OPenn CS/CNscheduler.cs.penn.edu
/OUMD CS/CNstorage.cs.umd.edu
/OPenn CS/CNex0001.cs.penn.edu
22
Questions?

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