[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43D7F4D0F915956AE54B00B1@duke.wrkhors.com>
Date: Wed, 20 Oct 2004 16:36:30 -0400
From: Steven Lembark <lembark@...hors.com>
To: owl-users@...ts.openwall.com
Subject: Re: sudo: why not?
> 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.
Catch: priv'd accounts can depend on context. What may be
less priv'd in one context (say, dba access vs. reformat the
disks) can be more priv'd in another (say, modify someone's
payroll record).
> 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.
You can also refuse superuser logins over the network (from
the root username or any other with UID 0). At that point
someone has to compromise the system enough to modify the
login rules before they can get in as root via the network.
You can restrict the number of users with simple access to
the command via mods, which allows revoking access to the
command by removing a user from one group (vs. having to
change the password). While not perfect, this does simplify
the most common cases where ex-employees have su access
because Jow Bloe in accouting couldn't be notified of the
change.
> 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.
You have better odds of turning off one non-priv'd account
than modifying any superuser accounts on a running system.
> 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).
Just create multiple accounts with UID 0, fine.
Only catch there is that looking for multiples with 0 is
one of the fastest ways to catch many rootkit attempts.
I normally modify the 'root' account to log the incomming
IP for legal action and create another SU for real work.
If there are multiple 0's in the UID then I have a real
problem.
> 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
> variables.
OK. So there is no perfect security short of a trusted
advisor with a loaded, cocked 44 watching whomever is
on the console...
> "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.
Hack sudo to jam-load -i behavior.
> 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.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@...hors.com 1 888 359 3508
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
