[NCLUG] Sudo

[Bob Proulx]

Onyx wrote:
> When using 'sudo', does anyone know of an efficient way to setup the 
> sudoers file so that a particular group (ie: wheel) can execute all root 
> commands, but cannot become root (through the means 'su' or any other form).

If you only allow the authorized users to execute a specific set of
commands and those commands do not allow further access, such as
spawning a shell, then that should be sufficient.  And pretty much
that is the only way to do it.  This is what I do on my systems.  For
example something like this:

  Cmnd_Alias      SHUTDOWN = /usr/sbin/shutdown -r now
  Cmnd_Alias      APACHECTL = \
          /etc/init.d/apache2 start, \
          /etc/init.d/apache2 stop, \
          /etc/init.d/apache2 restart, \
          /etc/init.d/apache2 reload, \
          /etc/init.d/apache2 force-reload
  ADMINS          ALL= APACHECTL, SHUTDOWN
  User_Alias     ADMINS = bob

> I tried defining something like the following, but it didn't seem to do 
> the trick.

Often people have tried to do something like this.  But it does not
work.  At best it is a reminder that it is undesirable to spawn a
shell (because the command is not tracked in that case) but it cannot
be enforced.  For the people who are conscientious this is not
needed.  For the others it is not effective.

> %wheel  ALL=ALL, !SU, !SHELLS

Because ALL is allowed in the above I could simply do the following.

  sudo vi safefile
  :sh

Or I could do this:

  cp /bin/bash /tmp/bash
  sudo /tmp/bash

Basically imagine a filelist with every file path currently on the
system added with every *potential* file path that may exist on the
system at some point in the future.  The latter is an infinite set of
paths.  From infinitity subtract a few known su and shell locations.
The set that is left behind is still an infinite set.

At best you might be able to audit /bin/, /usr/bin/, /sbin/,
/usr/sbin/, and develop a list of commands that you don't want the
user to run from those directories.  (Don't include vi, vim, emacs,
xemacs, or any other that can spawn shells.)  Then authorize those
entire directories and blacklist out the commands that you don't want
users to run.  Then whenever you install additional software update
the lists.  But I think this is an impractical amount of work.

Bob