On Thu, 2006-01-05 at 11:59 -0600, Tommy Reynolds wrote: > Uttered n0dalus <n0dalus+redhat@xxxxxxxxx>, spake thus: > > > I know other distributions do this, but I don't think it is a good > > idea. Adding the first user to /etc/sudoers means that any malware > > only needs to get that user's password, or get itself to run after you > > use sudo, and then it gets root access. > > > > I don't see what is wrong with using su. > > 1) Once any non-admin learns the root password, everybody knows the root > password. And unless the admin wants to do every trivial admin > activity, the root password must be given out and thus compromized. You do not give the root password out to those who should not have it. Very simple. Giving sudo access to a shell is just as bad as giving out the root password. > > 2) Root logins are security problems because you can't tell which > human actually logged on in the guise of root. Whom do you fire, > even if you figure out what was done? That's rarely an issue - accounting does keep track of who used su to obtain root. remote root login should never be allowed, it should require an su - or login from the console, which can be access restricted. > > 3) Sudo(1) allows fine control over which programs a user can run as > any other user. Yes - and it is a useful tool when it is properly administered. That means you don't set up a weak default like OS X and some Linux distributions do. > > 4) With sudo(1), an authenticated user must reauthenticate to run a > program as another user. (Trusted users need not reauthenticate.) > > 5) Sudo(1) logs the activity so you will have an audit trail. System > console, and syslog. Which can easily be modified (unless you are using a properly secured log server) if sudo can spawn a shell. > > > Using sudo(1) is a big security win. In some cases, properly administered by someone who understands sudo and the implications of sudo. > Unfortunately, the man(1) page > is a bit confusing for newbies and using su(8) seems so convenient. > But with a small setup step, I can safely allow: > > $ sudo rpm -Uvh /path/to/a/package > > to be run by a trusted user because I'll get notices about it the > attempt, its success or failure, as well as getting a record about > what command line was used. I would never allow sudo to use an rpm. An rpm sciptlet can do a lot of damage. I might allow sudo to invoke yum - with signature checking, so that a user could use yum localinstall - in which case packages not signed by trusted GPG key would fail. The options that could be passes to yum would have to be very limited though. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
