On Monday, 01/19/2009 at 04:03 EST, Rob van der Heij <[email protected]> wrote:
> > It isn't about passwords, per se. Rather, many (most?) sites prohibit > > remote login of root *by any means*. > > The sad thing about such directives is that they live much longer than > the person who initially dictated them (and still might know the > motivation behind this). Once such rules are established, you can't > easily change them anymore. This is the subtle trap that organizations fall into. By making it difficult to Do The Common Sense Thing, people start looking for shortcuts. (Ever look at a college campus? The sidewalks are ignored. But where are the lights placed for safety? Near the sidewalks....) > The two-step approach for root login has nothing to do with > encryption. When you have a plain old telnet session, the root > password that you type still travels over the wire to the system. > The motivation behind the two-step approach is a poor man's approach > to separate authentication and access control. When someone leaves the > department he may still remember the root password, but if you take > away his local account so that knowledge is less useful to him. But > when the root password is commonly known, then the added value of it > is minimal. Shared passwords of ANY sort destroy accountability. If you want your audit trail to tell a compelling story, make sure every person or process/program logs in with their own id. > I think "sudo" asking for the root password is in the same range of > useless rituals that create the illusion of security. And when you > logged on to the system, asking again for your password is of little > value (more likely to be picked up by the user watching over your > shoulder). When you're concerned about sessions remaining unsecured > open too long, then address that (by locking the workstation). I don't > have high expectations of per-command access granularity implemented > in sudo. But I do appreciate it for the auditing. When you use LDAP to > associate users with groups, it is very easy to handle access control > for sudo as well. If an intermediary is asking for root's password, then you haven't accomplished anything by using sudo. In fact, security is WORSE because of the pacifying effect of sudo. > When dealing with folks who need to work in emergency situations > (doctors, system programmers), attempts to limit their access often > creates a lot of discussion (and for a good reason). Those are no > routine tasks and you can't predict all steps needed. In those cases, > I believe strongly in fairly open access for approved staff, combined > with auditing (and justification afterwards). The auditing is also > helpful to diagnose problems and learn from the steps followed to > resolve the problem. System programmers using their access to tamper > with the auditing should be handled with care. There is trust and there is Trust (the latter includes a measure of "personal integrity"). For those whom you Trust, root access is permitted, but do it by giving them all uid 0, not by sharing passwords. Since each user has a different pid, the audit trail can be more closely examined to see who did what. (Watch out for a reducation program that gives you a username when you have shared uids.) Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
