Re: Sudo vs. Super
On Fri, 15 Aug 1997 David_Neuer@stream.com wrote:
> The subject line of this message is pretty self explanatory. Anyone have any
> idea of the relative strengths and weaknesses of these 2 products?
>
> Dave Neuer
They're limited in my view. There is no "usage" reporting,
accountability logging, no real granular control over
command access or command prototyping. I can't require a
certian number of arguments to a command, or restrict
certain arguments to a command, or enforce certain arguments
to a command, all on a per user basis. This is bad. I also
can't restrict usage within a specified period, or other
arbitrary criteria. I can't limit the scope of access
to a specific region of the system, or range of
resources, or put other arbitrary limits on it.
There is no uid/euid tracking from point of system access to
ensure rule base enforcement (i.e. if I log in as usera and
use super or sudo to somehow compromise the system and
"become" userb, I can now access userb's rules definitions
in sudo/super. This shouldn't happen. I should always be
usera to super/sudo -- even if I "su - userb" with the
valid passwd[1]. This "identity" tracing is being enforced
on machine "clusters" in some commercial products (MemCo,
SASadmin, etc.) I think it will one day be enforceable on
larger clusters, or even networks. In the mean time, using
sudo/super is convenient, but insecure (in my view) and not
really up to wide spread commercial use (especially in _any_
kind of mission critical situation.)
Even if sudo/super are implemented in a "rock solid" manner,
there are no limits to the "su-ness" granted. There could
be an issue unrelated to sudo/super that cause system
disaster, or breech unintentially. If there were ways to
limit the scope of privialage, any privilage granted
couldn't be exploited -- even if the system has been
otherwise.
For example, I should be able to grant a user the ability to
run an svga game if I choose. If somehow the svga game has
been compromised to create come kind of tunnel, it sholdn't
be able to access privliged data areas, or resources
(sockets, etc.) and thus be limited to the scope of the "su"
definition. This should be just what's required to run the
game. That would render trojan horses and viri harmless in
any other context. This type of control is absent from
these tools, and as such makes them a liability IMHO.
[1] This may sound strange, but consider the case where the
real uid of userb is achieved by usera through other means,
after usera has gaind authorized access as usera. This
normally amounts to the same thing as having the password
for userb. Thus, no discrimination between methods.
Just my 2.36 JPY
DISCLAIMER: I haven't seen recent versions of these
programs and some of the above issues may have been
addressed by now, but its not likely.
Cheers,
--
"Until we extend the circle of our compassion to all living
things, we will not ourselves find peace" -Albert Schweitzer
Richard G. Roberto
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: