| Rev | Author | # | Line |
|---|---|---|---|
| 1 | AristotlePagaltzis | 1 | !!! A short guide to setting up sudo(1) |
| 2 | |||
| 8 | DanielLawson | 3 | [sudo | http://www.sudo.ws/] is configured in the <tt>/etc/sudoers</tt> file, which is documented in sudoers(5). That man page is somewhat daunting at first, as it uses an [EBNF] to describe the configuration, however there are good examples near the end which cover most typical requirements. |
| 1 | AristotlePagaltzis | 4 | |
| 8 | DanielLawson | 5 | Please make sure you read the security section at the end. |
| 6 | |||
| 7 | !!! Configuring sudo | ||
| 1 | AristotlePagaltzis | 8 | |
| 9 | Be aware that sudo(1) is very picky about correct syntax in its configuration file and will refuse to work if you make the slightest mistake. (Considering that sudo(1) can grant SuperUser privileges, this is not an entirely bad idea, user-unfriendly as it may be.) Therefore, you should use the visudo(1) tool to edit the file, rather than opening it directly. <tt>visudo</tt> will check your changes for correctness after saving them, and will inform you of any errors, in which case it will offer to reject the changes or re-edit the file. Of course, <tt>visudo</tt> itself requires SuperUser privileges, so launch it using <tt>su -c visudo</tt>. | ||
| 10 | |||
| 3 | AristotlePagaltzis | 11 | Note that <tt>visudo</tt> may insist on making you use vi(1) to edit the file, though some configurations may respect your choice of TextEditor according to the <tt>EDITOR</tt>/<tt>VISUAL</tt> EnvironmentVariable~s. If this bugs you, edit <tt>/etc/sudoers</tt> with another editor, then use <tt>visudo -c</tt> to check it for correctness. (You can add an incantation to <tt>/etc/sudoers</tt> to tell <tt>visudo</tt> what <tt>EDITOR</tt>/<tt>VISUAL</tt> settings to respect, but that's pointless to discuss here since most people are only ever going to edit the file once.) |
| 1 | AristotlePagaltzis | 12 | |
| 8 | DanielLawson | 13 | !! Sudo and passwords |
| 14 | |||
| 9 | AristotlePagaltzis | 15 | Sudo operates in two modes with respect to passwords – it needs them or it doesn't. The <tt>NOPASSWD</tt> configuration token states that no password is needed for this block – if that token is not present, the user will have to type in their password. |
| 8 | DanielLawson | 16 | |
| 17 | Note that sudo does not escalate any priviledges for the original user. All priviledged commands must still be executed through the sudo command. | ||
| 18 | |||
| 19 | ! Which password? | ||
| 20 | |||
| 21 | Sudo requires the user that is calling sudo to enter ''their'' password. This is an important disctinction, because it means you can delegate administrative responsibility to users without having to supply everyone with the root password. | ||
| 22 | |||
| 23 | ! Password Caching | ||
| 24 | |||
| 25 | Sudo's default configuration is to cache a password for 5 minutes. This does allow some possibility of a security hole; see notes below for more details. | ||
| 26 | |||
| 27 | |||
| 28 | !! Notes on examples | ||
| 29 | |||
| 30 | The following sections all assume a couple of things: | ||
| 9 | AristotlePagaltzis | 31 | |
| 32 | * You are using visudo (or a similar program) to edit <tt>/etc/sudoers</tt>. See the notes above for more information on this | ||
| 33 | * There are two users, <tt>jack</tt> and <tt>jill</tt>, on the machine | ||
| 34 | * <tt>jack</tt> is a member of the unix group <tt>wheel</tt>, jill is not | ||
| 35 | * <tt>jack</tt> and <tt>jill</tt> are both members of the unix group <tt>users</tt> | ||
| 36 | * I use the whoami(1) command, because it reports the user ID, and is therefore effective in showing the change in privilege. | ||
| 8 | DanielLawson | 37 | |
| 38 | !! Basic format | ||
| 39 | |||
| 40 | The basic format of the user specification in the sudoers file looks like: | ||
| 41 | |||
| 42 | <verbatim> | ||
| 43 | user hostlist = (userlist) commandlist | ||
| 44 | </verbatim> | ||
| 45 | |||
| 9 | AristotlePagaltzis | 46 | * <i>user</i> is the name of the user or group to which this rule applies |
| 47 | * <i>hostlist</i> is a list of hosts this rule applies to | ||
| 48 | * <i>userlist</i> is a list of users that this rule can be run as. and must be enclosed in ( ) | ||
| 49 | * <i>commandlist</i> is a list of commands that this rule states can be executed | ||
| 8 | DanielLawson | 50 | |
| 9 | AristotlePagaltzis | 51 | The userlist token is optional – if excluded, it defaults to <tt>root</tt>. |
| 8 | DanielLawson | 52 | |
| 53 | All three of hostlist, userlist and commandlist can be replaced with the token <tt>ALL</tt>, allowing unrestricted access in each situation. | ||
| 54 | |||
| 55 | !! Setting sudo to allow a user to run commands as root | ||
| 56 | |||
| 9 | AristotlePagaltzis | 57 | This is the most common usage of sudo – it lets a specific user run all commands as the root user, without having to know the root password. Many modern linux distributions (such as Ubuntu) configure this by default for the first user of the system. |
| 8 | DanielLawson | 58 | |
| 59 | <verbatim> | ||
| 60 | jill ALL = ALL | ||
| 61 | </verbatim> | ||
| 62 | |||
| 63 | This says that the user jill will be able to execute all commands as root from all hosts. Jill will be required to enter her password. | ||
| 64 | |||
| 65 | !! Setting sudo to allow a group to run commands as root | ||
| 66 | |||
| 67 | It is useful to configure sudo to allow an entire group of users, such as the <tt>wheel</tt> group, to run sudo. Rather than having to configure sudo each time you wish to add or remove a user, you merely keep the group list updated. | ||
| 68 | |||
| 69 | <verbatim> | ||
| 70 | %wheel ALL = ALL | ||
| 71 | </verbatim> | ||
| 72 | |||
| 73 | This says that all users in the group wheel, eg jack, will be able to execute all commands as root, from all hosts. Jack will be required to enter his password. | ||
| 74 | |||
| 75 | |||
| 76 | !! Setting sudo to not require a password | ||
| 77 | |||
| 9 | AristotlePagaltzis | 78 | In many situations people wish to not have to enter a password. This is useful if you are the only user on the machine, or if you really trust your admin users and know that they keep good security with respect to their passwords, accounts, [SSH] keys, and so on. |
| 8 | DanielLawson | 79 | |
| 80 | <verbatim> | ||
| 81 | %wheel ALL = NOPASSWD: ALL | ||
| 82 | </verbatim> | ||
| 83 | |||
| 84 | This lets all users in the wheel group run all commands, from all hosts, without having to enter their password ever. Note that they still have to use the sudo command! | ||
| 85 | |||
| 86 | If you don't wish to deal with groups, you can of course substitute a username in for the %wheel token: | ||
| 87 | |||
| 88 | <verbatim> | ||
| 89 | jack ALL = NOPASSWD: ALL | ||
| 90 | </verbatim> | ||
| 91 | |||
| 92 | !! Only allowing a user to run a particular command | ||
| 93 | |||
| 94 | There are plenty of situations in which you might want a user to be able to run a command, or a list of commands, but not to have full access to the system. For example, you might wish to let any user on the system run the pon and poff commands, to bring a dialup link up or down on demand. | ||
| 95 | |||
| 96 | <verbatim> | ||
| 97 | %users ALL = NOPASSWD: /usr/bin/pon, /usr/bin/poff | ||
| 98 | </verbatim> | ||
| 99 | |||
| 100 | This lets all users in the unix group <tt>users</tt> run, without entering a password, the commands /usr/bin/pon and /usr/bin/poff. | ||
| 101 | |||
| 102 | It's important to provide a complete path, as if you merely include the executable name, a user could gain root access through malicious code execution. | ||
| 103 | |||
| 104 | !! Running commands as a different user. | ||
| 105 | |||
| 9 | AristotlePagaltzis | 106 | Sudo lets you run commands as the root user by default – but you can also configure it to allow you to run commands as any user. To do this we add another token to the configurations mentioned above |
| 8 | DanielLawson | 107 | |
| 108 | eg: | ||
| 109 | <verbatim> | ||
| 110 | %users ALL = ALL | ||
| 111 | </verbatim> | ||
| 112 | Will let all users in the unix group <tt>users</tt> run all commands as root, but not as other users: | ||
| 113 | |||
| 114 | <verbatim> | ||
| 115 | $ whoami | ||
| 116 | jack | ||
| 117 | $ sudo whoami | ||
| 118 | root | ||
| 119 | $ sudo -u jill whoami | ||
| 120 | Sorry, user jack is not allowed to execute '/usr/bin/whoami' as jill on localhost.localdomain. | ||
| 121 | </verbatim> | ||
| 122 | |||
| 123 | <verbatim> | ||
| 124 | %users ALL = (ALL) ALL | ||
| 125 | </verbatim> | ||
| 126 | Will let all users in the unix gorup <tt>users</tt> run all commands as all users: | ||
| 127 | |||
| 128 | <verbatim> | ||
| 129 | $ whoami | ||
| 130 | jack | ||
| 131 | $ sudo whoami | ||
| 132 | root | ||
| 133 | $ sudo -u jill whoami | ||
| 134 | jill | ||
| 135 | </verbatim> | ||
| 136 | |||
| 137 | Use this wisely! Of course, if you allow a user to run any command at all as root, they can always change to another user anyway. | ||
| 138 | |||
| 139 | |||
| 140 | !! Command and Host aliases | ||
| 141 | |||
| 142 | Sudo allows you to specify lists of commands and hosts to use instead of having to type out each one each time. I'm not going to cover host aliases, because they don't really apply to single-user or per-host configurations of /etc/sudoers. Read the man pages if you want some examples. | ||
| 143 | |||
| 144 | ! Command aliases | ||
| 145 | |||
| 146 | A simple command alias might look like the following: | ||
| 147 | |||
| 148 | <verbatim> | ||
| 149 | Cmnd_Alias SU = /usr/bin/su | ||
| 150 | </verbatim> | ||
| 151 | |||
| 152 | You can provide a list of commands, of course: | ||
| 153 | |||
| 154 | <verbatim> | ||
| 155 | Cmnd_Alias SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \ | ||
| 156 | /usr/local/bin/tcsh, /usr/bin/rsh, \ | ||
| 157 | /usr/local/bin/zsh | ||
| 158 | </verbatim> | ||
| 159 | |||
| 9 | AristotlePagaltzis | 160 | These can be used in place of the commandlist token |
| 8 | DanielLawson | 161 | |
| 162 | !! Restricting commands | ||
| 163 | |||
| 164 | You might wish to allow users the ability to run most commands, but to restrict a few. Eg, let's say you don't want your users to be able to run the 'su' command, or to execute a shell, as the root user. | ||
| 165 | |||
| 166 | This requires the SHELLS and SU command aliases are configured, as per the previous section of this document. | ||
| 167 | |||
| 168 | <verbatim> | ||
| 169 | %users ALL = ALL, !SU, !SHELLS | ||
| 170 | </verbatim> | ||
| 171 | |||
| 172 | |||
| 173 | !!! Usage of sudo | ||
| 174 | |||
| 9 | AristotlePagaltzis | 175 | If sudo has been configured to not required a password for the particular command you are trying to execute, it will “just work.” |
| 8 | DanielLawson | 176 | |
| 9 | AristotlePagaltzis | 177 | If the <tt>NOPASSWD</tt> token has not been set, you will be prompted to enter your password the first time you try to execute sudo |
| 8 | DanielLawson | 178 | |
| 179 | <verbatim> | ||
| 180 | $ sudo whoami | ||
| 181 | Password: | ||
| 182 | root | ||
| 183 | $ date | ||
| 184 | Sun Aug 28 10:05:44 NZST 2005 | ||
| 185 | </verbatim> | ||
| 186 | |||
| 187 | Sudo is configured by default to cache your password for some time, such as 5 minutes. Note that this counter is reset every time you run sudo. Consider it a 'time since last used'. If you run sudo again within this time, you will not be asked for a password: | ||
| 188 | |||
| 189 | <verbatim> | ||
| 190 | $ date | ||
| 191 | Sun Aug 28 10:06:13 NZST 2005 | ||
| 192 | $ sudo whoami | ||
| 193 | root | ||
| 194 | </verbatim> | ||
| 195 | |||
| 196 | And if you then wait for 5 or more minutes, and try again, you will once more be asked to enter your passwd: | ||
| 197 | <verbatim> | ||
| 198 | |||
| 199 | $ date | ||
| 200 | Sun Aug 28 10:06:13 NZST 2005 | ||
| 201 | $ sudo whoami | ||
| 202 | Password: | ||
| 203 | root | ||
| 204 | </verbatim> | ||
| 205 | |||
| 206 | Note that the password caching applies for the user calling sudo only. It is not, by default, restricted through any other mechanism such as the TTY you are logged in on, or the command you are executing: | ||
| 207 | |||
| 208 | <verbatim> | ||
| 209 | $ sudo whoami | ||
| 210 | Password: | ||
| 211 | root | ||
| 212 | $ sudo touch /root/newfile | ||
| 213 | $ sudo chmod 0600 /root/newfile | ||
| 214 | $ sudo ls -la /root/newfile | ||
| 215 | -rw------- 1 root root 0 Aug 28 10:09 /root/newfile | ||
| 216 | </verbatim> | ||
| 217 | |||
| 218 | !!! Security and sudo | ||
| 219 | |||
| 220 | !! sudo does not allow unverified SuperUser access to a normal user | ||
| 221 | |||
| 222 | When you wish to execute commands as root, or as another user, you must still use the sudo command: | ||
| 223 | |||
| 224 | <verbatim> | ||
| 225 | $ sudo whoami | ||
| 226 | root | ||
| 227 | $ whoami | ||
| 228 | jack | ||
| 229 | </verbatim> | ||
| 230 | |||
| 231 | !! sudo does not grant SuperUser access to users. | ||
| 232 | |||
| 233 | It grants access ''to particular commands'' to users. Only the permitted commands can be subsequently invoked via sudo by the originally invoking user. | ||
| 1 | AristotlePagaltzis | 234 | |
| 8 | DanielLawson | 235 | !! Is sudo a security hole? |
| 1 | AristotlePagaltzis | 236 | |
| 8 | DanielLawson | 237 | Some people perceive sudo as a security flaw in a system. In practice, it's not really much worse than giving people the root password. Consider the following scenario: |
| 1 | AristotlePagaltzis | 238 | |
| 8 | DanielLawson | 239 | ''An attacker discovers the password of an administrative user account (jack) on a machine. He can use this to log into the machine directly. He discovers that jack has sudo access, and can now completely take over the machine.'' |
| 1 | AristotlePagaltzis | 240 | |
| 8 | DanielLawson | 241 | Seems quick, huh? This isn't really a problem with sudo, as much as a problem with jack's poor password security. What might have happened otherwise? Consider this: |
| 1 | AristotlePagaltzis | 242 | |
| 8 | DanielLawson | 243 | ''An attacker discovers the password of an administrative user account (jack) on a machine. He can use this to log into the machine directly. After logging in, he discovers that the kernel is vulnerable to a local root escalation exploit, and so he downloads and compiles an appropriate rootkit, executes it, and can now completely take over the machine.'' |
| 1 | AristotlePagaltzis | 244 | |
| 8 | DanielLawson | 245 | Slightly more work, but you have to consider that people who break into machines *already have* these tools available. How about another couple of situations: |
| 1 | AristotlePagaltzis | 246 | |
| 9 | AristotlePagaltzis | 247 | ''An attacker discovers the password of an administrative user account (jack) on a machine. He can use this to log into the machine directly. He checks through jack's .bash_history file and notices a random-looking sequence of characters the line before 'su' is executed. He runs 'su', and uses this sequence of characters, and his hunch pays off – he now has a root shell on the machine.'' |
| 1 | AristotlePagaltzis | 248 | |
| 9 | AristotlePagaltzis | 249 | ''An attacker discovers the password of an administrative user account (jack) on a machine. He can use this to log into the machine directly. He checks the kernel, it is not vulnerable to any known local root escalation exploits. He instead downloads a trojaned version of the 'su' command to the machine. This program will intercept the user's attempt to authenticate with the root password, storing the password, before passing it all on to the real version. The hacker then modifies jack's PATH to include this binary before everything else, so that when jack runs the 'su' command, it will run the trojaned version. The hacker receives an email from his program a day later – jack has used the trojan su command, and given away his root password. The hacker can now completely take over the machine.'' |
| 2 | PerryLorier | 250 | |
| 5 | SimonBridge | 251 | |
| 9 | AristotlePagaltzis | 252 | Whether any of the above scenarios are feasable or not is another matter – the point is that once an attacker has a local shell on your machine, all bets are off. It is almost certain they will have installed a trojan somewhere, or will have already gained root already through other mechanisms. Sudo doesn't really make this much worse. |
| 7 | AristotlePagaltzis | 253 | |
| 8 | DanielLawson | 254 | That said, there are some practical things you can do to increase sudo security |
| 4 | SimonBridge | 255 | |
| 8 | DanielLawson | 256 | !! Decrease the cache timeout: |
| 4 | SimonBridge | 257 | |
| 9 | AristotlePagaltzis | 258 | You can set sudo to expire its password cache sooner than the default 15 minutes, by setting the <tt>timestamp_timeout</tt> option to something else in <tt>/etc/sudoers</tt>. |
| 4 | SimonBridge | 259 | |
| 8 | DanielLawson | 260 | !! Force expire your password token: |
| 4 | SimonBridge | 261 | |
| 8 | DanielLawson | 262 | If you know you have finished using sudo for now, use <tt>sudo -k</tt> to expire your tokens right now. This could be included in a .bash_logout script to force expiring tokens when you logout of a machine, or your screensaver could be configured to execute it for you. |
| 4 | SimonBridge | 263 | |
| 9 | AristotlePagaltzis | 264 | !! Prevent <tt>TTY</tt> attacks |
| 4 | SimonBridge | 265 | |
| 9 | AristotlePagaltzis | 266 | sudo doesn't care about which <tt>TTY</tt> you are logged in on by default. Eg., if I login on one console, run sudo and enter my password, then login on another console, and run sudo again, my password is already cached. This could be bad if you left yourself logged in elsewhere by accident – say on another machine. |
| 4 | SimonBridge | 267 | |
| 9 | AristotlePagaltzis | 268 | sudo can be compiled with the <tt>USE_TTY_TICKETS</tt> option, which will limit a ticket to a particular <tt>TTY</tt>. Not many distributions seem to do this however. |
| 4 | SimonBridge | 269 | |
| 8 | DanielLawson | 270 | ! References |
| 9 | AristotlePagaltzis | 271 | * [SuDo security threat prevention | http://www.securiteam.com/unixfocus/3Y5QCR5N5O.html] |
| 272 | * [Sudos (and Sudon'ts) | http://www.oreillynet.com/pub/wlg/9326] – some lessons from practice for larger installations | ||
| 11 | LawrenceDoliveiro | 273 | * [Sudo humour|http://xkcd.com/c149.html] |
| 10 | AristotlePagaltzis | 274 | |
| 275 | ---- | ||
| 276 | CategoryHowto |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 4 times)