How Not to Use Sudo =================== Part of IT's job is controlling *who* has access to elevated privileges, and *what* they are permitted to do with that access. We're not only protecting studio assets, but end user data and expectations of privacy. This is healthy paranoia. LAIKA is a "trust but verify" environment - sudo usage is logged. Or at least, it *would be*, if it were set up **properly**. Anyone who doesn't think `root` is a big deal doesn't understand what is possible with uid 0. Among the obvious "delete any file" and/or "screw up the computer" kind of tasks, here's a few things that could cause serious issues for someone (and definitely for IT)... And again, this is healthy paranoia. It's quite possible this list is derived from things that end users have actually done in the past. *cough cough* * Install a key logger * Man-in-the-Middle network traffic (even SSL) * Run disruptive services on privileged ports (DHCP) * Impersonate other employees * Get other employee private data * Get company private data * Wanton destruction (angry employee) * Destroy logs and accounting of **all** above said actions, making such actions near impossible to trace (at best), or completely invisible (at worst). To this end, giving an end user full `root` access should practically *never* be done. Instead, `sudo` rules (fed from LDAP) should be explicitly set up. Each usage of `sudo` is streamed to syslog (and potentially logged to local disk via `sudoreplay`). More technical end users will balk. They hate this. Once this is simply the default policy, it's easy to not make exceptions, and it should be advertised that this protects everyone -- including them. Logging alone is **NOT ENOUGH** if the user can use poorly crafted sudo rules to gain full root. Here are some examples of terrible practices, and why they are "bad". Bad Ideas --------- I'll use Tony as an example for things. No disrespect. ### Allowing a global `!noexec` dn: cn=taiello,ou=users,ou=sudo,dc=laika,dc=com objectClass: sudoRole objectClass: top cn: taiello description: Machines Tony Aiello has root on. sudoCommand: ALL sudoHost: zennla sudoOption: !noexec <------- NO `execve` is a system call that allows a unix process to spawn another, completely different process. The rules above allow Tony to run any command he pleases on `zennla` (and it'll be logged.) Only the initial command will be logged, however. There are a *LOT* of unix utilities (far too many to blacklist) that can spawn subcommands. Using the common command `more` as an example: holp ~ > id uid=2014(mahlon) holp ~ > echo test > testfile holp ~ > sudo /usr/bin/more testfile Password: test --More--(END) !echo test > elevated_test !done (press RETURN) holp ~ > ls -l testfile elevated_test -rw-r--r-- 1 root wheel 5 Jun 3 09:21 elevated_test -rw-r--r-- 1 mahlon anim 5 Jun 3 09:20 testfile Yep. Even `more` can exec arbitrary commands. After sudo is granted, I can now exec **anything I want** as root, and it isn't logged. The initial logged command looks completely benign, and there's no way to tell the difference. With `noexec` left alone as the default: --More--(END) !echo test > elevated_test sh: /bin/tcsh: Permission denied Note that there *are* situations where a command needs `!noexec`, such as extracting a compressed tarfile. In these instances, a separate entry should be added for specificly that. Never make this option global. ### Not using absolute command paths dn: cn=taiello,ou=users,ou=sudo,dc=laika,dc=com objectClass: sudoRole objectClass: top cn: taiello description: Machines Tony Aiello has root on. sudoHost: zennla sudoCommand: mysql <------- NO Question number one: Why would that command require root access at all? The mind boggles. More importantly, this allows a user with rudimentary unix know-how to create an executable called `mysql` that lives anywhere and does anything. Witness. $ cat > mysql <