== The security model of _sudo_ versus _su_

Some time ago I wrote about [[the three faces of _sudo_ SudoThreeFaces]],
where one of the faces was basically '_sudo_ as the replacement for
_su_ in how sysadmins get unrestricted root privileges' and I said
that this created a different security model than with _su_. Today
I want to talk about what that new model is and how I see it differing
from _su_'s in a way that makes me like it less.

To start with we need to talk about the security model of _su_. Su
has a simple security model: you must know the root password and
generally be in a restricted group. Then you can either get a root
shell or execute a command as root by giving _su_ the root password,
and you must do this for every shell or command that you want.

(If your version of _su_ is not configured to require membership
in group 'wheel' or the local equivalent, the security model is
that anyone at all who knows the root password can use _su_ to
assume root powers.)

Sudo's normal security model is that if you are in a restricted
group and know your own password, you can run commands as root or
get a root shell by typing your own password. Once you've typed
your password once you can then run commands as root without any
prompt for a certain amount of time.

There are two big differences between these two security models.  The
first is the choice of password that you are challenged with, where
_sudo_'s choice is noticeably weaker. With sudo the security of root
access rests not on the root password alone but the passwords of
everyone who has root access. Since people's regular passwords are
used much more often and more broadly than the root password, my
view is that they are more exposed ([[including stored in programs
../sysadmin/LostPasswordBattle]]). An attacker who compromises even one
sysadmin password now has immediate access to root by logging in as the
sysadmin and repeating the password that they already know; they don't
need to compromise an additional secret.

The second is that _sudo_ effectively creates a temporary environment
where you have root powers by using a magic prefix. An attacker
that can detect this environment (or try blindly) and inject commands
into it (either directly or, for example, via a shell script that
you're running) can hijack this special power even without knowing
your password and immediately use root powers. My view is that this
makes a post-_sudo_ shell session unusually dangerous and damaging.
It also somewhat increases the possibility of simple accidents,
since an errant _sudo_ command will go through without a pause that
would give you a chance to reconsider.

Either or both of these changes can be turned off via _sudoers_
settings. But then you've reduced _sudo_ to a variant of _su_.
Maybe that's what you want (_sudo_ does have better logging than
_su_ and some additional features), but I don't think it's the
common way to use _sudo_ as a _su_ replacement. Maybe I'm wrong
here, though; I'd be interested to hear if places that use _sudo_
as a _su_ replacement turn off these.