Differences between version 8 and previous revision of SudoHowto.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 8 | Last edited on Sunday, August 28, 2005 10:48:54 am | by DanielLawson | Revert |
| Older page: | version 7 | Last edited on Sunday, August 28, 2005 2:14:44 am | by AristotlePagaltzis | Revert |
@@ -1,75 +1,269 @@
!!! A short guide to setting up sudo(1)
-[sudo | http://www.sudo.ws/] is configured in the <tt>/etc/sudoers</tt> file, which is documented in sudoers(5). Unfortunately
, that ManPage seems written for people who want to write a clone of sudo, rather than use
it, so it is unnecessarily difficult
to understand
the syntax by reading its documentation. The task is further complicated by
the fact that the syntax is somewhat baroque
.
+[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
.
- ''Hint to
the sudo programmers: humans are not yacc parsers, so a parser grammar is not suitable documentation
.''
+Please make sure you read
the security section at the end
.
+
+!!! Configuring sudo
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>.
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.)
-With all
that said
, let
's proceed
to the disproportionately short piece
of configuration text
that all this noise had
to be made about
. Copy
the following line into
the file
:
+!! Sudo and passwords
+
+Sudo operates in two modes with respect to passwords - it needs them or it doesn't. The 'NOPASSWD' 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.
+
+Note that sudo does not escalate any priviledges for the original user. All priviledged commands must still be executed through the sudo command.
+
+! Which password?
+
+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.
+
+! Password Caching
+
+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.
+
+
+!! Notes on examples
+
+The following sections all assume a couple of things:
+* You are using visudo (or a similar program) to edit /etc/sudoers. See
the notes above for more information on this
+* There are two users, jack and jill, on the machine
+* jack is a member
of the unix group <tt>wheel</tt>, jill is not
+* jack and jill are both members of the unix group <tt>users</tt>
+* I use the 'whoami' command, because it reports the userid, and is therefore effective in showing the change in privilege.
+
+!! Basic format
+
+The basic format of the user specification in the sudoers file looks like:
+
+<verbatim>
+user hostlist = (userlist) commandlist
+</verbatim>
+
+* The 'hostlist' is a list of hosts this rule applies to
+* The 'userlist' is a list of users
that this rule can be run as. and must be enclosed in ( )
+* The 'commandlist' is a list of commands that this rule states can be executed
+
+The userlist token is optional - if excluded, it defaults to <tt>root</tt>.
+
+All three of hostlist, userlist and commandlist can be replaced with the token <tt>ALL</tt>, allowing unrestricted access in each situation.
+
+!! Setting sudo to allow a user to run commands as root
+
+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.
+
+<verbatim>
+jill ALL = ALL
+</verbatim>
+
+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
.
+
+!! Setting sudo to allow a group to run commands as root
+
+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.
+
+<verbatim>
+%wheel ALL = ALL
+</verbatim>
+
+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.
+
+
+!! Setting sudo to not require a password
+
+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.
+
+<verbatim>
+%wheel ALL = NOPASSWD: ALL
+</verbatim>
+
+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!
+
+If you don't wish to deal with groups, you can of course substitute a username in for the %wheel token:
+
+<verbatim>
+jack ALL = NOPASSWD: ALL
+</verbatim>
+
+!! Only allowing a user to run a particular command
+
+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.
+
+<verbatim>
+%users ALL = NOPASSWD: /usr/bin/pon, /usr/bin/poff
+</verbatim>
+
+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.
+
+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.
+
+!! Running commands as a different user.
+
+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
+
+eg:
+<verbatim>
+%users ALL = ALL
+</verbatim>
+Will let all users in the unix group <tt>users</tt> run all commands as root, but not as other users:
+
+<verbatim>
+$ whoami
+jack
+$ sudo whoami
+root
+$ sudo -u jill whoami
+Sorry, user jack is not allowed to execute '/usr/bin/whoami' as jill on localhost.localdomain.
+</verbatim>
+
+<verbatim>
+%users ALL = (ALL) ALL
+</verbatim>
+Will let all users in the unix gorup <tt>users</tt> run all commands as all users:
+
+<verbatim>
+$ whoami
+jack
+$ sudo whoami
+root
+$ sudo -u jill whoami
+jill
+</verbatim>
+
+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.
+
+
+!! Command and Host aliases
+
+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.
+
+! Command aliases
+
+A simple command alias might look like
the following:
+
+<verbatim>
+Cmnd_Alias SU = /usr/bin/su
+</verbatim>
+
+You can provide a list of commands, of course:
+
+<verbatim>
+Cmnd_Alias SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
+ /usr/local/bin/tcsh, /usr/bin/rsh, \
+ /usr/local/bin/zsh
+</verbatim>
+
+These can be used in place of
the 'commandlist' token
+
+!! Restricting commands
+
+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.
+
+This requires the SHELLS and SU command aliases are configured, as per the previous section of this document.
+
+<verbatim>
+%users ALL = ALL, !SU, !SHELLS
+</verbatim>
+
+
+!!! Usage of sudo
+
+If sudo has been configured to not required a password for the particular command you are trying to execute, it will 'just work'.
+
+If the NOPASSWD token has not been set, you will be prompted to enter your password the first time you try to execute sudo
+
+<verbatim>
+$ sudo whoami
+Password
:
+root
+$ date
+Sun Aug 28 10:05:44 NZST 2005
+</verbatim>
+
+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:
+
+<verbatim>
+$ date
+Sun Aug 28 10:06:13 NZST 2005
+$ sudo whoami
+root
+</verbatim>
+
+And if you then wait for 5 or more minutes, and try again, you will once more be asked to enter your passwd:
+<verbatim>
+
+$ date
+Sun Aug 28 10:06:13 NZST 2005
+$ sudo whoami
+Password:
+root
+</verbatim>
+
+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:
+
+<verbatim>
+$ sudo whoami
+Password:
+root
+$ sudo touch /root/newfile
+$ sudo chmod 0600 /root/newfile
+$ sudo ls -la /root/newfile
+-rw------- 1 root root 0 Aug 28 10:09 /root/newfile
+</verbatim>
+
+!!! Security and sudo
+
+!! sudo does not allow unverified SuperUser access to a normal user
+
+When you wish to execute commands as root, or as another user, you must still use the sudo command:
+
+<verbatim>
+$ sudo whoami
+root
+$ whoami
+jack
+</verbatim>
+
+!! sudo does not grant SuperUser access to users.
+
+It grants access ''to particular commands'' to users. Only the permitted commands can be subsequently invoked via sudo by the originally invoking user.
-<pre>
-%wheel ALL=(ALL) NOPASSWD: ALL
-</pre>
+!! Is sudo a security hole?
-That
's it. Now all users in
the group <tt>wheel</tt>, by longstanding [Unix] tradition the group which contains the SystemAdministrator~s, will be able to use <tt>sudo</tt> to invoke any command, running as any user (but defaulting to
root), without being prompted for a
password. Of course, this requires putting your regular user account in that group; if there really will only ever be one user to use <tt>sudo</tt> on your machine, you can omit this step by using
the line
+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:
-<pre>
-username'' ALL=
(ALL
) NOPASSWD: ALL
-</pre>
+''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.''
-!!! A longer guide to setting up
sudo(1)
+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:
-[sudo | http://www.sudo.ws/] offers many more capabilities than just letting one or more users do anything at all as anyone at all. That flexibility is why it
's so hard
to configure in
the first place, and is very useful
in actual multi-user situations
, where some users only need to be able
to do one (or
a few) specific thing(s) requiring SuperUser privileges
.
+''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
.''
-F.ex.
, such a scenario might involve a webmaster who should be able
to restart the WebServer which runs as <tt>root</tt>, and be able to kill any processes which run as <tt>wwwuser</tt> or some other unprivileged account
that the WebServer uses to actually deliver pages, but should not
have full root access to the machine
.
+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:
-''However, I mostly wanted to have a quick description on how to set up sudo
(1
) for people who run [Linux]
on their home [PC]s, so I'm not going
to go
into that here and now
. I may come back to this at some point
. In
the meantime, there
is useful material about that available via [Google]
. --AristotlePagaltzis
''
+''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.
''
+''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.''
-!!! Common Misconceptions About sudo(1) and Security
-<i>NB: the following section applies mainly to more sophisticated setups
of sudo(1) than
the one shown in the </i>Short guide<i>
above.</i>
+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
.
-Since its inception
, the possibility that providing SuperUser access on a normal user password could represent a security hole has tickled the imagination of [Hacker] and user alike. While
there have been special cases of misusing sudo(1) so as to circumvent network security, [
some security bulletins | http://www.securiteam.com/unixfocus/3Y5QCR5N5O.html] would seem
to make more of the issue than there is. The purpose of this section is to clear up misconceptions that commonly occur about the use of
sudo(1) in practise. Hopefully, this will allow sysadmins and users, concerned about
security, to direct their energies to more serious issues.
+That said
, there are
some practical things you can do
to increase
sudo security
-__[sudo(1)] does not allow unverified SuperUser access to a normal user.__ This misconception that it does comes from a misreading of
the sudo(1) man page. One understands that after first invoking sudo(1), one no longer need enter a password for future uses (within a time limit). One also understands that the user access has been upgraded for the duration of this time limit. This leads to the following possible uses coming tomind
:
+!! Decrease
the cache timeout
:
- <verbatim>
- $
sudo iptables -L
-
password:
- <iptables information>
- ... time, less
than 5 mins
, passes ...
- $ iptables -L
-
</verbatim
>
+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 /etc/sudoers
-The second invocation of iptables(8) would fail. The user cannot execute commands which require SuperUser privileges directly. To execute this command without requiring a
password, the user would have to enter <tt>sudo iptables -L</tt>.
+!! Force expire your
password token:
-
<verbatim
>
- $
sudo iptables
-L
- password:
-
<iptables information
>
-
... time
, less than 5 mins, passes
...
- $ sudo mount <some file system at some mountpoint>
- </verbatim>
+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
.
-Here, because the commands differ, the invocation of mount(8) would still require a password -- even though sudo(1) has already been invoked and verified within the "magic" 5 min time frame. (Note: Superuser access in not required to mount(2) a filesystem, provided it is entered in fstab(5) with the "user" option.)
+!! Prevent TTY attacks
-__[
sudo(1)] does not grant SuperUser access to users.__ It grants access
''to particular commands'' to users
. Only the permitted commands can be subsequently invoked via
sudo(1) without a
password by the originally invoking user
. The following example shows the correct behavior:
+sudo doesn
't care about which TTY 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
.
- <verbatim>
- $ sudo whoami
- password:
- root
- $ whoami
- user
- $ sudo whoami
- root
- $ sudo whereis sudo
- password:
- sudo: /usr/bin/sudo /usr/share/man/man8/
sudo.8
.gz
- </verbatim>
+sudo can be compiled with the USE_TTY_TICKETS option, which will limit a ticket to a particular TTY
. Not many distributions seem to do this however
.
-The first invocation of sudo(1) for the whoami(1) command required a password. Invoking whoami(1) without sudo(1) shows that you are still a normal user. Future invocations of <tt>whoami<
/tt> with the aid of sudo(1) do not require a password
. Attempting to sudo(1) any ''other'' command ''will'' requires a password
. (Note: <tt>whereis<
/tt> does not need root to be used, but sudo(1) requires verification anyway: it is not verifying your right to use the command, but your right to use sudo(1)
.)
+! References
+* http:
//www
.securiteam
.com
/unixfocus/3Y5QCR5N5O
.html
