[NCLUG] Re: Who uses SUDO on production machines?

Chad Perrin perrin at apotheon.com
Mon Mar 19 12:31:43 MDT 2007


On Mon, Mar 19, 2007 at 10:27:20AM -0600, mike loseke wrote:
> The use of SUDO, along with the black-and-white view of system security, is
> subjective to a great many things. Everyone should evaluate the tools and
> policies they are putting in place to make sure that they meet the
> requirements of the need/project/system/site/etc. There is no global right
> or wrong - we'll save that for the vi/emacs discussions :).

Obviously, vi.

Oh, that wasn't an invitation.  Sorry.


> 
> Personally, I dislike SUDO. For the work I do, like Sean, I get that "are
> you about to do something dangerous" type of mindset when I'm working on a
> system that I'm responsible for. That's not to say that I champion it's
> avoidance. There are situations where it's a very good solution. When it
> *is* used, great care needs to be taken to set it up properly so that the
> system itself is protected at the level it needs to be for that application
> and that the users for whom it is setup can do the work they need to do
> successfully. Applications like Sean mentioned are an excellent example of
> this.

I tend to agree -- both that the security choices of each individual
circumstance needs to be assessed separately, and that the change of
context can be invaluable in ensuring that one is more careful when
operating as root.  For me, all it took to make that lesson stick was
typing "shutdown -h now" into the wrong TTY console, SSHed into the
wrong system, while I worked for the Wikimedia Foundation.  Hilarity
ensued.  I never did it again.


> 
> The same with security. As the old saying goes, the only secure system is
> the one encased in concrete and dropped into the deepest part of the ocean.
> Unfortunately, usability and access have been traded off the scale in favor
> of that absolute. There are applications, like home users, or labs (R&D, not
> students), where security of almost any sort is not a concern. In most
> cases, these systems may not be networked or will be firewalled into their
> own little network cave, but here we're trading off these other things like
> access/usability for slackened security - which in the proper place can
> improve usability.

Again, agreed.  My philosophy, however, is that one is best served by
aiming for a secure system, then scaling back the type of security to be
implemented until it reaches a level of reasonability for one's
purposes.  I never set out to put together a system with effectively no
security at all.  I've had too many systems repurposed without a nuke
and pave of the OS in my life to intentionally leave out security
measures for no reason other than the fact that I don't think I'll need
them.


> 
> Anytime you're looking to setup a system, the security of that system needs
> to be taken into account anytime any usability/access issues arise. If it's
> on the open net, it deserves as much attention to making it secure as can be
> applied to it or you'll be rebuilding the system and cleaning up after it at
> least several times a year. If it's on the bench in your garage and you're
> using it to control battlin' lego-bots then you have a different focus.
> 
> Anyway, just saying that even though many people will champion a
> black-and-white view of any of these topics, you as the person/group
> responsible for that system need to consider the tools to be used and the
> levels of security to put in place.
> 
> And always verify your backups.

Excellent closing statements.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid



More information about the NCLUG mailing list