Differences between version 7 and previous revision of SudoHowto.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Sunday, August 28, 2005 2:14:44 am | by AristotlePagaltzis | Revert |
| Older page: | version 6 | Last edited on Friday, August 26, 2005 2:09:38 pm | by CraigBox | Revert |
@@ -18,10 +18,8 @@
<pre>
''username'' ALL=(ALL) NOPASSWD: ALL
</pre>
-
-<br><br>
!!! A longer guide to setting up sudo(1)
[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.
@@ -29,60 +27,49 @@
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.
''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''
-----
-As an aside, the first time you use it, sudo(1) presents you with a few helpful hints to remember including a spiderman quote:
-<verbatim>
- #3) With great power comes great responsibility.
-</verbatim>
-Gold!
!!! Common Misconceptions About sudo(1) and Security
-Since it's inception, the possibility that providing SuperUser access on a normal user password could represent a security hole has tickled the imagination of [hacker|Hacker] and user alike. While there have been special cases of misusing sudo(1) so as to circumvent network security, security bullitins like [ this | http://www.securiteam.com/unixfocus/3Y5QCR5N5O.html] would eem 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.
-<b
>"
sudo(1) allows unverified SuperUser access to a normal user"
</b
> (This is
<i>not
</i> true.)
-This misconception 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:
+<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>
+
+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.
-<b>example
1:</b>
-<verbatim>
-$
sudo iptables -L
-:
-<iptables information>
-..
. time, less than 5 mins, passes
...
-$ iptables -L
-<iptables information>
-</verbatim>
+__[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:
-<b>example 2:</b>
-
-$ sudo iptables -L
-password:
-<iptables information>
-... time, less than 5 mins, passes ...
-$ sudo mount <some file system at some mountpoint>
-<mount complete without password or error>
-</verbatim>
+
<verbatim>
+
$ sudo iptables -L
+
password:
+
<iptables information>
+
... time, less than 5 mins, passes ...
+
$ iptables -L
+
</verbatim>
-If either
of these examples seem reasonable to you, then you have been taken in by this common and subtle misconception
. You are encouraged to try these out
. (Note: Superuser access in not required to mount(2)
a filesystem
, provided it is entered in fstab(5) with
the "
user" option
.)
+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>
.
-In example 1, the second invokation of iptables(8) would fail. To execute this command without requiring a password requores the user enter
<tt
>sudo iptables -L</tt
>.
+
<verbatim
>
+ $
sudo iptables -L
+ password:
+
<iptables information
>
+
... time, less than 5 mins, passes ...
+ $ sudo mount <some file system at some mountpoint>
+ </verbatim>
-In example 2
, the invokation
of <tt>
mount</tt>
would still require a password - even though sudo has already been invoked and verified within the "magic" 5 min time frame.
+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.)
-<b>Sudo
does not grant SuperUser access to any user
.</b> The
access is granted
to a <i>single command</i> only
. Only that one command
can be subsequently sudoed
without a password, and only
by the original
invoking user. So the
following example shows the correct behavior:
+__[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:
-<b>example 3:</b>
-
-$ 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>
+
<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>
-The first invokation
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 invokations
of sudo(1) do not require a password for the command "<tt>whoami</tt>"
. Attempting to sudo(1) any <i>
other</i>
command still
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).)
+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).)
