|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Security Practices question
On Thu, Oct 03, 2002 at 09:57:10AM -0700, [email protected] said: > On Thu, 3 Oct 2002, Scott Francis wrote: > > On Wed, Oct 02, 2002 at 05:48:16PM -0700, [email protected] said: > > In an environment where every sysadmin is interchangable, and any one > > of them can be woken up at 3am to fix the random problem of the day, > > you tell me how to manage 'sudoers' on 4000 machines. > > You don't _have_ logins directly to 4000 machines. You have a central admin > host (or five) with user-level accounts. Those user-level accounts can 'sudo > ssh <target>' to accomplish things as root on the remote boxes. > > So you propose that a trust relationship over the network is a more > secure solution? I can't believe you're advocating allowing ssh logins > as root as a better idea than per-admin uid 0 accounts. Absolutely. Make logins restricted to a specific host or hosts, key-based auth only ... heck, put a private NIC on each box and make it so that sshd only binds to an RFC1918 address. You think multiple uid zero accounts on each box is more secure than this? Or worse, easier to manage? > Given the nature of the UNIX permissions structure, any solution > is going to be lacking when scaled up large enough - but the > problems involved in properly administering sudo are considerly > smaller than those introduced by having mulitple uid 0 accounts > (especially multiple uid 0 accounts on multiple machines). > > You still haven't given me a single example of what these "problems" > are. Just hand-waving and talk about the "right" way is. I thought the comment below would have illustrated the potential management nightmare introduced by having multiple uid zero accounts per machine. If it did not, I don't know how to make it any more clear. > What do you do when one (or ten) of those 'interchangeable syadmins' leaves > the company? _Then_ you have a real nightmare - changing root and removing > uid 0 accounts on 4000 boxes. I'd rather manage /etc/sudoers, thanks very > much. > > Are you paying attention? If one of the admins leave, his accounts > (user and UID 0) are deactivated. The password on the "root" account YES - but deactivated on EACH of 4000 boxes?! > doesn't need to be changed, assuming he/she didn't know it. Where's He/she ALREADY HAD IT! What multiple uid zero accounts amounts to is multiple equally valid passwords for the SAME ACCOUNT. When somebody has root, and they leave, anybody with enough sense to _be_ a sysadmin immediately changes /all/ root-level accounts and accesses in the network, anywhere the ex-employee had access. To do otherwise is foolhardy at best. > the nightmare there? Its the same level of effort that managing the > sudoers file. If thats a nightmare in your environment, I'm sorry, > you've got bigger problems. managing sudoers across a network is dead simple - either use a central, tightly-controlled admin host/hosts, or else use rsync+ssh keys to propagate changes. > > In an situation where the team needs root; all per-admin UID 0 > > accounts add is accountability and personalized shells/environments. > > All of which can be handled with sudo, without giving away the keys to the > castle. > > An open sudo configuration (which Barb is advocating in her latest > post) gives away those same keys. So I don't see what the benefit here > is. I don't think anybody ever advocated an open config - I, at least, think ALL=(ALL) ALL offers few benefits over simply handing out the root password (which is still less troublesome than creating multiple root-level accounts). I personally think the best practice is default deny - take away _everything_, and then add only what is really needed. A case should be made for every superuser ability that is requested. (anyway, I promised I'd stop with this thread. If you're interested in debating this issue further, I'll be happy to do so off-list.) regards, -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui Attachment:
pgp00009.pgp
|