Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Oct 2004 23:55:16 +0400
From: Solar Designer <>
Subject: Re: sudo: why not?

Hi Mike,

On Sun, Oct 17, 2004 at 12:18:02AM +0400, Mike Belopuhov wrote:
> I'm just skipping some gratitudes to Owl team ;-) and just asking
> a question: why sudo is not in Owl?  Always when I install Owl I
> can't guess why it is so.  It works fine with tcb.

Yes, but unfortunately both su and sudo are subtly but fundamentally

Presently, the only safe use for su is to switch from a more
privileged account to a less privileged one (whenever this distinction
can be made) in a non-interactive script (without a tty).  As soon as
a tty is used, there is a security problem.  As soon as you su to a
more privileged account, there is another security problem.

We've been discussing privately how we might re-design su (or
improve Linux kernel interfaces) such that su would become safe in
presence of tty's.  However, even if that is done, su would still be
unsafe for accessing more privileged accounts from less privileged

Yes, it used to be common sysadmin wisdom to "su root" rather than
login as root.  Those few who, when asked, could actually come up with
a valid reason for this preference would refer to the better
accountability achieved with this approach.  Yes, this really is a
good reason in favor of this approach.  But it's also the only one.
And the reason I give against using this approach is that it
effectively allows anyone who could have compromised the otherwise
non-privileged user account used to su from to gain root (at the
next invocation of su by the admin).  So the separation between the
non-root and the root accounts is lost.

The alternative to "su root" is direct root logins.  If there're
multiple persons who need root privileges on a server, multiple root
privileged accounts may be created, -- which Owl now includes full
support for (note our msulogin package).

Now, let's approach your question about sudo.  As you can imagine, it
too has the problems of su.  A privilege is meant to be granted to a
non-user account temporarily, -- however, anyone who could have
compromised the account, even if they do not know the password (e.g.,
for a compromise through a CGI script or an FTP/IRC/whatever client
vulnerability), can gain ahold of the sudo-elevated privilege
permanently (by intercepting one sudo session during which the
password would be entered).

The above property is inherent to sudo.  However, besides it, there's
also an implementation defect.  sudo uses a blacklist, as opposed to a
whitelist, for disallowing "bad" environment variables from being
passed on to the program specified in the sudoers file.  No blacklist
can be complete.  The result of this is that it is generally possible
for a user listed in sudoers to get full shell access as the target
user (usually root) even if the specified command was meant to allow
for a certain action only.  On Owl, this problem is largely remedied
by the glibc -owl-sanitize-env.diff patch which strips glibc's own
risky environment variables on SUID exec (e.g., of sudo itself) such
that they would not be present on subsequent non-SUID execs (e.g., of
the command specified in sudoers).  But this is not something I like
to rely upon, and it only works for glibc.  The program invoked from
sudo may use other libraries and it may support its own environment

"sudo -i" almost achieves the desired effect (environment fully reset,
then populated with known-safe entries), except that there's no way to
force this behavior from a configuration file.

Of course, we may fix this implementation defect with a patch.  But
you've asked "why no sudo", -- and the above is the current answer.

Hope it helps, and thank you for trying to help.

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ