1 / 11

Privilege Separation in Condor

Privilege Separation in Condor. Bruce Beckles University of Cambridge Computing Service. No privilege separation:. root. Condor daemons. Condor job. Privilege separation:. root Condor daemons. Condor job. What is privilege separation?.

jameshuffman
Download Presentation

Privilege Separation in Condor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Privilege Separation in Condor Bruce Beckles University of Cambridge Computing Service

  2. No privilege separation: root Condor daemons Condor job • Privilege separation: root Condor daemons Condor job What is privilege separation? • Isolation of those parts of the code that run at different privilege levels

  3. Condor job How do we do this? • Privilege switching: root Condor daemons • GNU userv allows one process to invoke another (in either the same or a different user context) in a secure fashion when only limited trust exists between them (see http://www.gnu.org/software/userv/).

  4. Who does what? • Execute hosts: • Change ownership of any file (CAP_CHOWN capability) • Switch to any user context (CAP_SETUID capability) • Send signals to any process (CAP_KILL capability) • Submit hosts: • Switch to any user context (CAP_SETUID capability) • Send signals to any process (CAP_KILL capability) • Central manager: • No privilege switching required (unless GSI authentication is being used, in which case need to be able to switch to any user context (CAP_SETUID capability)) (Note that if you have the ability to switch to any user context you effectively have the ability to send signals to any process.)

  5. Current Status (1) • Only implemented on execute hosts • Uses GNU userv for “privilege switching” • Uses standard Condor facility (USER_JOB_WRAPPER) to pass the Condor job to a “wrapper” script, which is then responsible for executing the job • Some limitations (details later) • In use at the University of Cambridge

  6. Details – Execute host • No Condor daemon or process runs as root • Condor passes job to our wrapper script • Our script installs a signal handler to intercept Condor’s signals to the job • Our script changes the ownership of the job’s files (via userv) as necessary at beginning and end of job • Our script fork()’s a userv process which runs the job in a different (also non-privileged) user context • On receipt of a signal from Condor, our script calls userv to send the signal to the job • userv uses pipes to pass the job’s standard output and standard error back to our script (and so to Condor) • A cron job (using Condor’s STARTD_CRON mechanism) runs once a minute to make sure that if there is no job executing then there are no processes running in our dedicated “Condor job” user context

  7. What does this gain us? • If there is a vulnerability in Condor then the entire machine is not compromised as a result. • We do not have any Condor processes, whose real user ID is root, listening to the network. • Much greater control over the job’s execution environment – could run the job chroot’d if desired. • Our wrapper script can examine the job and make more sophisticated decisions about whether or not to run it (restrict to local executables, etc.) • If a Condor job leaves behind any processes running after job completion they will be killed – normally, Condor only does this properly if specially configured (EXECUTE_LOGIN_IS_DEDICATED).

  8. What do we lose? • Can no longer suspend jobs (cannot catch SIGSTOP) • We now need to handle passing the job environment variables, setting resource limits and scheduling priority, etc., which Condor would normally handle • Condor can no longer correctly distinguish between the load Condor processes and Condor jobs are putting on the machine, and the load generated by other processes • Information returned by Condor about the job’s CPU utilization, etc. is incorrect • Does not yet work with Condor’s Standard universe (although this may not be difficult to fix)

  9. Current Status (2) • Implemented using shell scripts and GNU userv • No source code changes to Condor • In active development • Continual testing • Scripts available on request (but no support!)

  10. Future plans • Many of these limitations can be addressed by modifying the Condor source code • Working with the Condor Team to integrate privilege switching into the Condor source code – will hopefully appear in the development series sometime • Investigating privilege separation for submit hosts

  11. Questions? Thank you. Questions?

More Related