Sudo Access with Beowulf Clusters Chris Feehan CS Senior Capstone 12/18/06

Outline *Intro to Sudo Command *Configuring Sudo *Sudo w/ Clusters *Ethics & Security *Recommendations

What Exactly is Sudo? Access Configuration Tool Non-root as root w/out passwd *root=superuser Non-root as root w/out passwd *root=superuser By default, installed on most Unix-based OS’s Widely used at academic institutions and small, low- budget businesses Its FREE!

Sudo Configuration Prefix command with “sudo”, prompts for password, accepts or denies (example) “% sudo chmod u+rw file.txt” “% Password: _______” “% Password: _______” /etc/sudoers, /usr/sbin/visudo 2 Main Components: Aliases & User Specification

/etc/sudoers Example *ALIASALIASNAME = item1, item2,… //User_Alias SYSADMINS = Jensen, Feehan, //Host_Alias CLUSTERHEADS = castaway Cmnd_Alias DELEGATE = /bin/chgrp, /bin/chown Cmnd_Alias SHELLS = /bin/sh, /bin/bash, /bin/tcsh User Specification root (superuser) ALL = (ALL) ALL SYSADMINS CLUSTERHEADS = DELEGATE, !SHELLS

Why is sudo right for St. Olaf Beowulf Cluster? Free Expensive solutions= sysmark powerpassword Expensive solutions= sysmark powerpassword Highly Configurable Users perform specific tasks Users perform specific tasks Secure edit via VISUDO Locks sudoers file against multiple simultaneous edits Locks sudoers file against multiple simultaneous edits Provides basic sanity checks, checks for parse errors Provides basic sanity checks, checks for parse errors Powerful Logging facilities /var/log/sudo.log /var/log/sudo.log.bash_history.bash_history Allows for Least Privilege methodology Least access they need…minimizes any damage a user or attacker can make Least access they need…minimizes any damage a user or attacker can make

Sudo Risks Sudo passwords Every account w/ full sudo access= < attacker likelihood for success Every account w/ full sudo access= < attacker likelihood for success How can they get access to passwords? How can they get access to passwords? /etc/shadow via sudo Sudo hijacking By default, Sudo uses tickets--password caching By default, Sudo uses tickets--password caching Multiple sessions per user with same ticket! Multiple sessions per user with same ticket! Attacker can piggyback on sudo privileges w/out his/her password Prevent tip: disable password caching

Piggyback Attack SysAdmin John logs into ClusterHead John runs Sudo Command Sudo Password is cached for 5 min: John logs off Attacker Gains Access to John’s Terminal Session Attacker Uses Sudo without John’s password

Sudo Risks (cont) Sudo Escalation Exclusion vs. Inclusion Exclusion vs. Inclusion if improperly configured, Limited Sudo  Full Sudo JeffALL = ALL, !SHELLS Copy /bin/sh to /home Then run “sudo /home/sh” Logged in as ROOT Run “sudo /bin/sh” Error: Not Allowed by sudo

Recommendations How to delegate privileges w/ Beowulf cluster? Currently, only active configuration of sudo is root =ALL, admin=ALL Currently, only active configuration of sudo is root =ALL, admin=ALL StudentAdmin/Project Leader--learn sudo inside and out Don’t make the mistake of using exclusion. Start Basic—increase privileges as necessary If configuring sudo, also should configure ssh Don’t want anyone logging into childnodes as root PDF Report on Secure Automation with Sudo & SSH Robert Napier—Cisco Systems

Questions?