Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Disempowering the singular sysadmin

Anonymous Coward writes | more than 3 years ago

IT 3

An anonymous reader writes "Practically every computer system appears to be at the mercy of at least one individual who holds root or whatever other superuser identity can destroy (or subvert, etc.) that system. Each application on a system has the same weakness. However, making a system require multiple individuals for any root operation (think of the classic two-keys to launch a nuke) has shortcomings: simple operations sometimes require root, and would be enormously cumbersome if they needed a consensus of administrators to execute. There is the idea of a Distributed Administration Network, which is like a cluster of independently-administered servers, but this is a limited case for deployment of certain applications... and anyway it is still presumably vaporware. Are there more sweeping yet practical solutions out there for avoiding the weakness of a singular empowered superuser?"

cancel ×

3 comments

Sorry! There are no comments related to the filter you selected.

Multiple empowered superusers (1)

Spazmania (174582) | more than 3 years ago | (#34798054)

Best solution I've found is: multiple empowered superusers, heavily automated backups and the practice of hiring competent, trustworthy staff.

Re:Multiple empowered superusers (1)

ron_ivi (607351) | more than 3 years ago | (#34800358)

This.

Plus good logging of anything done as a superuser.

Best place I worked (from an IT point of view) had everyone with "sudo" capabilites, but everything done as sudo was logged and reviewed by the IT staff. Need to make a change as root - no problem - especially if you stuck to commands where they could pretty easily see what you did and why. And yes, you got yelled it very quickly if you 'sudo bash' and did a bunch of unnecessary stuff as root.

It also had a live day-old-hot-backup (/yesterday) you could mount in case anyone did anything abusive or if you messed up yourself; and comprehensive backups going back a long time.

Solution looking for a problem (1)

KublaiKhan (522918) | more than 3 years ago | (#34798802)

Organizations that would be impacted by a 'singular sysadmin' already take measures to counter that possibility.

For instance, in an organization that I have worked with, the principle of assigning least privelege is adhered to strictly: users are given as little privelege as possible; helpdesk personnel only have enough privelege to modify computer settings (install printers and the like) and modify AD entries for the users in their section; progressively higher--more priveleged--levels require progressively more hurdles before they can make their changes.

And further, everything is traceable and documented; changes made without authorization are easily detectable and capable of being rolled back; the associated accounts can be locked down quickly for investigations as necessary.

Does it make it a bureaucratic nightmare to get things done? For normal business cases, no; if the user needs software installed, they submit a request to the helpdesk, and they get their software--assuming that they're authorized for it, anyway, but licensing is a whole other kettle of fish.

This is all possible because the possibility of a single person holding control over the network was recognized as undesirable at the start, and measures were taken to ensure that many administrators would hold the keys to making changes, and that they would be held accountable for said changes.

Similar principles hold in other places as well--this is how most large enterprise networks work (some are managed better than others), and most open-source projects with any success rate will operate their repositories in a similar fashion, with access controls, least-privelege, and accountability being built into their procedures from the beginning.

This DAN sounds, to me, like an overcomplicated anarcho-collectivist "let's make everybody important!" kind of communal fuckery. Especially with the "forking" thing, you're almost guaranteed to end up with vast quantities of incompatible systems fighting each other to determine the One True Path. It's too complicated to work effectively, and there will be too much bureaucratic overhead to make any decisions in an agile enough fashion to matter.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>