[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4176E158.3030207@op5.se>
Date: Thu, 21 Oct 2004 00:06:16 +0200
From: Andreas Ericsson <ae@....se>
To: owl-users@...ts.openwall.com
Subject: Re: sudo: why not?
Steven Lembark wrote:
>
>> 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).
>
The root user could access the database files physically
(binaryphorically speaking) and thus already has this privilege. There
is really no such thing as security against the superuser.
>> 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.
>
Apart from a single exploitable bug in a networking daemon running as
root. Or a single exploitable bug in any non-chrooted networking daemon
and a single (or series of, possibly) exploitable local bugs that leads
to elevated privileges.
> 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.
>
The users you want to safeguard against are the ones that doesn't need
just "simple" access to the command.
>> 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.
>
Would you care to elaborate? Are you assuming the position of an
attacker or the position of an admin in that statement?
>> 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.
Rootkits needs root access to be installed. We're trying to prevent that
altogether, not make sure we can find them once they're installed.
> 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.
>
uid 1000 has three. Is that 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...
>
Actually, not even that would be perfectly secure, but it would make it
harder for anyone sitting there to go berzerk without being noticed.
Again, we're not interested in noticing things when they've happened,
but rather to prevent them.
>> "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.
>
Feel free. I'm sure it's not a terribly difficult or burdensome task,
but it's not on the Owl todo.
>> 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.
>
--
Andreas Ericsson andreas.ericsson@....se
OP5 AB www.op5.se
Lead Developer
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.
