On Fri, 15 Aug 1997 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
