zach miller computer sciences department university of wisconsin-madison zmiller@cs.wisc.edu ...

Zach MillerComputer Sciences DepartmentUniversity of Wisconsin-Madison

zmiller@cs.wisc.eduhttp://www.cs.wisc.edu/condor

Securing Condor

www.cs.wisc.edu/condor

Overview

› Problems With Default Installation

› Security Policy Configuration

› Configuring Security Methods

› Conclusion and Questions

www.cs.wisc.edu/condor

Problems With Default Installation

› Host-based granularity is too big Any user who can login to central

manager has “Administrator” privileges

Any user on a machine can evict the job on that machine via condor_vacate

www.cs.wisc.edu/condor

Problems With Default Installation

› Most connections are NOT authenticated Queue management commands are. Daemon-to-daemon commands are

not. It is possible to send false information

to the collector and other denials of service

www.cs.wisc.edu/condor

Problems With Default Installation

› Traffic is not encrypted or checksummed Possibility of someone eavesdropping

on your traffic, including files transferred to or from execute machine

Possibility of someone modifying your traffic without detection

www.cs.wisc.edu/condor

Security Policy Configuration

› Condor provides many mechanisms to address the previous shortcomings: Many authentication methods Strong encryption Signed checksums for integrity

www.cs.wisc.edu/condor

Security Policy Configuration

› Condor will negotiate security requirements and supported methods

clientserver

I want to submit a job

You must authenticate w/ kerberos

KERBEROSnormal submit protocol

www.cs.wisc.edu/condor

Security Policy Configuration

Default PolicySEC_DEFAULT_ENCRYPTION = OPTIONALSEC_DEFAULT_INTEGRITY = OPTIONALSEC_DEFAULT_AUTHENTICATION = OPTIONALSEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD #UNIXSEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI, KERBEROS, SSL, PASSWORD #WIN32

www.cs.wisc.edu/condor

Security Policy Configuration

Default Policy

Possible Policy ValuesNEVER do not allow this to happenOPTIONAL do not request it, but allow itPREFFERED request it, but do not require itREQUIRED this is mandatory

SEC_DEFAULT_ENCRYPTION = OPTIONALSEC_DEFAULT_INTEGRITY = OPTIONALSEC_DEFAULT_AUTHENTICATION = OPTIONALSEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD #UNIXSEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI, KERBEROS, SSL, PASSWORD #WIN32

www.cs.wisc.edu/condor

Security Policy Configuration

Y Y Y X

Y Y Y N

Y Y N N

X N N N

R P O N

Required

Preferred

Optional

Never

ClientPolicy

Server Policy

Policy Reconciliation

www.cs.wisc.edu/condor

Security Policy ConfigurationVery Secure Policy

SEC_DEFAULT_ENCRYPTION = REQUIREDSEC_DEFAULT_INTEGRITY = REQUIREDSEC_DEFAULT_AUTHENTICATION = REQUIREDSEC_DEFAULT_AUTHENTICATION_METHODS = SSL

SSL CONFIGURATION LATER IN THIS TUTORIAL

www.cs.wisc.edu/condor

Security Policy Configuration

Policy Reconciliation Example 1CLIENT POLICY

SEC_DEFAULT_ENCRYPTION = OPTIONAL SEC_DEFAULT_INTEGRITY = OPTIONALSEC_DEFAULT_AUTHENTICATION = OPTIONALSEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD

SERVER POLICYSEC_DEFAULT_ENCRYPTION = REQUIREDSEC_DEFAULT_INTEGRITY = REQUIREDSEC_DEFAULT_AUTHENTICATION = REQUIREDSEC_DEFAULT_AUTHENTICATION_METHODS = SSL

RECONCILED POLICYENCRYPTION = YESINTEGRITY = YESAUTHENTICATION = YESMETHODS = SSL

www.cs.wisc.edu/condor

Security Policy Configuration

Policy Reconciliation Example 2CLIENT POLICY

SEC_DEFAULT_ENCRYPTION = PREFERRED SEC_DEFAULT_INTEGRITY = OPTIONALSEC_DEFAULT_AUTHENTICATION = REQUIREDSEC_DEFAULT_AUTHENTICATION_METHODS = SSL, GSI, KERBEROS, PASSWORD

SERVER POLICYSEC_DEFAULT_ENCRYPTION = NEVERSEC_DEFAULT_INTEGRITY = PREFERREDSEC_DEFAULT_AUTHENTICATION = OPTIONALSEC_DEFAULT_AUTHENTICATION_METHODS = FS,GSI,SSL

RECONCILED POLICYENCRYPTION = NOINTEGRITY = YESAUTHENTICATION = YESMETHODS = GSI,SSL

www.cs.wisc.edu/condor

Security Policy Configuration

› As you can see, you may specify a different policy for each authorization level

Another Example PolicySEC_DEFAULT_ENCRYPTION = OPTIONALSEC_DEFAULT_INTEGRITY = PREFERREDSEC_DEFAULT_AUTHENTICATION = REQUIREDSEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, PASSWORD, SSL

SEC_READ_INTEGRITY = OPTIONALSEC_READ_AUTHENTICATION = OPTIONAL

SEC_CLIENT_INTEGRITY = OPTIONALSEC_CLIENT_AUTHENTICATION = OPTIONAL

www.cs.wisc.edu/condor

Security Policy Configuration

› Possible values for authorization levels: CLIENT READ WRITE CONFIG ADMINISTRATOR OWNER DAEMON NEGOTIATOR

www.cs.wisc.edu/condor

Security Policy Configuration

There is now a hierarchy of authorization:

READ

WRITE

DAEMONADMINISTRATOR

CONFIGOWNER

CLIENT

NEGOTIATOR

www.cs.wisc.edu/condor

Security Policy Configuration

Once you have authenticated users, you may use a more fine-grained authorization list:

ALLOW_WRITE = zmiller@cs.wisc.edu

ALLOW_WRITE = zmiller@cs.wisc.edu/goose.cs.wisc.edu

ALLOW_WRITE = zmiller@cs.wisc.edu/*.cs.wisc.edu

www.cs.wisc.edu/condor

Security Policy Configuration

› Format of canonical username:user@domain/host

› One wildcard allowed in the user@domain portion, and one allowed in the host portion

www.cs.wisc.edu/condor

Security Policy Configuration

› Usernames can now be mapped with regular expressions. Old GSI mapfile:

“/C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Zach Miller/Email=zmiller@cs.wisc.edu” zmiller@cs.wisc.edu

“/C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Todd Tannenbaum/Email=tannenba@cs.wisc.edu” tannenba@cs.wisc.edu

Etc.

www.cs.wisc.edu/condor

Security Policy Configuration

› New mapfile applies to all types of authentication

› In your condor_config:

SEC_CANONICAL_MAPFILE = /path/to/mapfile

› Each line is a mapping rule

www.cs.wisc.edu/condor

Security Policy Configuration

› Sample map file:

CLAIMTOBE .* nobody

FS (.*) \1

GSI Email=(.*) \1

www.cs.wisc.edu/condor

Security Policy Configuration

› Review: The security policy determines which

types of security mechanism will be used for a given type of command:

SEC_ADMINISTRATOR_AUTHENTICATION = REQUIRED SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = GSI

www.cs.wisc.edu/condor

Security Policy Configuration

› Review: The map file gives you a canonical

name from the authenticated user:GSI Email=(.*) \1

“/C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin – Madison/O=Computer Sciences Department/OU=Condor Project/CN=Zach Miller/Email=zmiller@cs.wisc.edu”

zmiller@cs.wisc.edu

www.cs.wisc.edu/condor

Security Policy Configuration

› Review: The ALLOW_ and DENY_ lists control

the authorization of the canonical users:

ALLOW_WRITE = *@cs.wisc.edu, zach@otherdomain.com

DENY_WRITE = *.evildomain.net

www.cs.wisc.edu/condor

Configuring Security Methods

CLAIMTOBE is not configurable, and is meant for testing purposes only.

ANONYMOUS is also not configurable, and always sends the username “CONDOR_ANONYMOUS”

www.cs.wisc.edu/condor

Configuring Security Methods

FS works by creating a file in /tmp, and checking to see who the owner of that file is.

FS_REMOTE is similar, but allows you to specify where to create the file, allowing you to use a directory on NFS or some other shared storage. This is specified like so:

FS_REMOTE_DIR = /shared/temp/space

www.cs.wisc.edu/condor

Configuring Security Methods

NTSSPI uses Windows’ SSPI authentication. This requires that the username and password be the same on two machines that are authenticating to each other. There are no configuration options for this method.

www.cs.wisc.edu/condor

Configuring Security Methods

GSI is the Globus Toolkit’s implementation of X.509. There are quite a number of configuration options for this which essentially specify which credentials to use, which to expect, and who is allowed to sign the credentials.

www.cs.wisc.edu/condor

Configuring Security Methods

When using GSI, a user typically has a public key (certificate) and a private key that is encrypted with a password.

A temporary certificate, called a proxy, is created for use with condor:

% grid-proxy-init -cert zmiller.crt -key zmiller.keyYour identity: /C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Zach Miller/Email=zmiller@cs.wisc.eduEnter GRID pass phrase for this identity:Creating proxy ............................................... Done

www.cs.wisc.edu/condor

Configuring Security Methods

For the Condor daemons to use GSI authentication, however, they will need either a proxy or a private key with no password.

Proxies would need to be valid for a considerable length of time to be useful in this context, so usually a cert/keypair is used.

www.cs.wisc.edu/condor

Configuring Security Methods

GSI_DAEMON_CERT = condor_cred.crt

GSI_DAEMON_KEY = condor_cred.key

Also, Condor needs to know the public key of any CA that signs certificates:

GSI_DAEMON_TRUSTED_CA_DIR=/path/to/keys

www.cs.wisc.edu/condor

Configuring Security Methods

Typically, there is a “host credential” which is owned by root in:/etc/grid-security/host.crt

/etc/grid-security/host.key

And also a directory of signing keys in/etc/grid-security/certificates

www.cs.wisc.edu/condor

Configuring Security Methods

Condor will use those defaults without any additional configuration, if it has root privilege to read the host key.

Alternatively, you can specify your own directory to hold the key files and the signing certificates by using:

GSI_DAEMON_DIRECTORY=~/globus/

www.cs.wisc.edu/condor

Configuring Security Methods

Since GSI is currently available only on UNIX systems, we have also added support for OpenSSL.

It needs essentially the same information as GSI, which is specified in this case with a different set of configuration parameters:

AUTH_SSL_SERVER_CAFILEAUTH_SSL_SERVER_CADIRAUTH_SSL_SERVER_CERTFILEAUTH_SSL_SERVER_KEYFILEAUTH_SSL_CLIENT_CAFILEAUTH_SSL_CLIENT_CADIRAUTH_SSL_CLIENT_CERTFILEAUTH_SSL_CLIENT_KEYFILE

www.cs.wisc.edu/condor

Configuring Security Methods

For both GSI and OpenSSL, you can use the openssl command line tool to create all the necessary keys and files.

For more detailed info on that, please see the openssl man page, or come to the security BOF Thursday @ 1:30.

www.cs.wisc.edu/condor

Configuring Security Methods

KERBEROS is now available on both UNIX and Windows platforms

On UNIX, it authenticates again a KDC (Kerberos Domain Controller). On Windows, the Active Directory server fills this role.

www.cs.wisc.edu/condor

Configuring Security Methods

For Kerberos, a user may need to run kinit if that is not part of the normal login process:

% kinit zmiller@CS.WISC.EDU

Password for zmiller@CS.WISC.EDU:

% klist

Ticket cache: FILE:/var/adm/krb5/tmp/tkt/tkt_24842_pid14957

Default principal: zmiller@CS.WISC.EDU

Valid starting Expires Service principal

04/24/06 12:01:07 05/24/06 12:01:07 krbtgt/CS.WISC.EDU@CS.WISC.EDU

www.cs.wisc.edu/condor

Configuring Security Methods

The Condor daemons can use the “host credential” if they are running as root. The default keytab file is typically in /etc/v5srvtab

Alternatively, you can specify your own keytab file and server principal to use:

KERBEROS_SERVER_KEYTAB = /scratch/zmiller/keytab.zmillerKERBEROS_SERVER_PRINCIPAL = zmiller/condor@CS.WISC.EDU

www.cs.wisc.edu/condor

Configuring Security Methods

PASSWORD authentication also works on both UNIX and Windows, although the interface is somewhat different.

On Windows, the password is stored in a secure part of the registry.

On UNIX, the password is stored in a file specified by:SEC_PASSWORD_FILE = /path/to/file

www.cs.wisc.edu/condor

Configuring Security Methods

To set the pool password, use the condor_store_cred command:

condor_store_cred add –p password

www.cs.wisc.edu/condor

Conclusion

Now you have seen a general overview of the different methods that Condor supports, how to configure them, and how to set policy so they get used where you want them.

www.cs.wisc.edu/condor

Questions?

Also, security BOF Thursday @ 2:30!