Why not run as root?

  • I stumbled across an interview with Michael Robertson of Lindows, Inc. at the Linspire 5 show. It's mostly a marketing spiel about their new version and their business philosophy, but there was one really interesting quote:

    I defy anybody to tell me why is it more secure to not run as root.

    Needless to say that provoked more than a few comments from the Slashdot crowd. And it's an interesting look at something that I've debated with other production people, especially the security folks at times.

    I'm an effective worker. Meaning that I work to get things done, quickly, accurately, and more importantly, in a way that makes the business move forward. Now in most places that I have worked, I've been one of the sys admins, and pretty much always a domain administrator. As such, I've typically done all types of tasks relating to being a Windows admin as well as a SQL admin. And typically my account has been linked to a system administrator in SQL Server as well.

    Now over time, we've evolved to the best practice that administrators have a "normal" user account for their normal work and an administrative account for administrative work. At JD Edwards I had an sj12345 account and an sa-sj12345 account for admin work. Security policy was to log in and run as your normal account (sj12345) and only log in or use your "sa account" for admin work.

    I never used my normal account. At least not beyond using it for testing things :). I'd get argued with by my boss, but my counter was always that pretty much everything I did was administrative related. Definitely my SQL Server work since if I wasn't doing some administrative task, I had no reason to log onto the SQL Servers. But even in answering my email and moving through file systems, I was pretty much always working on something administrative.

    And I made periodic mistakes, like deleting or moving an entire folder. But, after doing this for a number of years, I was no more or less likely to do this than others who only used their administrative account when they needed to. In fact, I tended to do it less. 🙂

    My reasoning is that as an administrator, you are constantly doing administrative work. And you get so used to this, that you'll be likely to run more and more things as administrator, like Explorer windows and you might forget which ones are "normal" and which are "administrator". And if you have windows open, a virus or other attack could easily get to the rest of your machine.

    I do understand that if you are running as a "normal" user and some IE or Outlook exploit takes over your machine, it won't go far, but I don't buy it in the real world. There's too much work to be done and you shouldn't be browsing all over creating while you're doing your admin work. Ideally, I think you need two machines, or a separate VM for admin work, but I've never been lucky enough when I've been an admin to get those things.

    I do, however, think that as a regular user, it does make sense to not run as an admin, but as a user and let things call for your admin password if needed, like installs. But Microsoft has to build that in, much like OS X for the Mac. Whenever I go to install something on my Mac, it prompts me for the admin password. It doesn't fail.

    Unlike every game my kids have for their XP machine.

    Steve Jones

  • I do the same, for much the same reasons. One of the things I teach anyone doing DBA/Jr DBA work is to always have a plan if you do something wrong, because sooner or later you WILL do something wrong. Most of the times when you err you needed the greater permissions to do the thing you were trying to do when it went south! Sometimes that is having a backup, scripting the old object out, or just doing a select into so that you have a table backup that is easy to access.

  • I set my kids' accounts on their WinXP computers as "Power User" so that they can install some programs without admin rights. Newer installers (and even many older ones) seem to detect this and ask for an Admin account and password to run the installer under. If they run into this, my wife or I go in and supply the credentials so the software will install. Occasionally the installer does not provide the warning in advance and just crashes but the kids know to just call Mom and Dad when something goes wrong anyway

    At least we're useful for something!

    My wife and I are admins on our PCs and the computer we use for burning and ripping CDs usually runs under an admin account since the software we use on it requires direct hardware access. This is probably not the best idea but we are diligent about keeping our anti-virus and anti-spyware software up-to-date. Ever since a friend inadvertently sent us a virus  we have been good about that and Windows Anti Spyware and AVG Free are good about reminding us.

    [font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
    Business Intelligence Administrator
    MSBI Administration Blog

  • The problem is that Microsoft have never understood security, and bad security is now so entrenched in the operating system (and the mindset of MS-only admins) that they probably never will.

  • I tend to agree that MS hasn't introduced security very well into their products. There are some very smart people up there and I know many of them understand how it works, but the pressures of backwards compatability and marketing have really pushed htem to take the easy way out.

    And it's no worse with users. Look at the XP SP2 complaints. They made some things more secure, seemed like a "test" to me to see how people would react and many people didn't want to apply it. Broke their apps.

    Security is a tough business, both for companies and users. I've seen it badly implemented across all platforms and occassionally, well implemented in any of them.

     

  • There's a big difference between Macs and Unix vs. Windows here. On OS X, a regular user can still perform admin functions with knowledge of an admin id and password. Linux has sudo (so does OS X). Under OS X, and admin level account still can't nuke the entire system. Under Windows, let's face it: you're either admin, who can spray junk all over the system, or you're not, and you can't really do to much. Sure, there's 'Run As...', but that doesn't work in every situation, and isn't half as elegant as the OS X solution.

    Windows does many things well. Security isn't one of them, however.

    So, under Unix and OS X, there's very little reason to run as root, as you can do the admin tasks you need to from a standard user account *without disrupting your workflow*. Under Windows, if you're doing more than basic e-mail and web browsing, you probably need admin at some point. Which means: logging out, getting admin, doing what you have to do, logging out, logging back in...sigh. Or, it means running as admin full-time. Neither Windows choice is appealing.

    --

    erm

  • I tend to agree, having a seperate account is unnecessary. If you don't know what you are doing and have not established safe practices such as pausing before you delete or update something you probably should not be an admin in the first place. 

    From what I have seen over my 25+ years in this industry most computer security measures are put in place to "Close the barn after the horses have already left". For  my work the best "security" mechanism is a seperate VM session where I can test any activity that is potentially risky prior to running it on the actual system. As anyone who as worked with VM's the ability to set up an environment, implement a change, examine the results and get back to the original unmodified enviromnent is priceless and far more secure than and having seperate accounts.

     

    Bernard Simmons

  • Maybe for a DBA it's unnecessary, for someone holding domain admin privs, that's a different story entirely. Case in point: nimda.

    If I'm running as a normal user account, think about the public shares I have access to. This is far fewer than the public shares I would normally have access to as a domain admin (which, by default, is a member of the local administrators group on a server and a lot of folks throw administrators into any share permission for troubleshooting, etc.). Now while we'd like everything to be a hidden share, this causes problems for end users and eventually public shares are deployed.

    The nimda worm spread by a multitude of ways. One of the ways was discovering public shares and replicating itself to them. If I'm reading email with my normal user account, chances are the amount of damage done is a whole lot less than if I'm reading email with my domain admin account.

    Now some would say antivirus is the answer but it's not. AV only comes into play when a worm/virus has been in the wild and they've had time to figure out proper definitions for it. That's why we've occassionally seen Symantec jump warnings up to cat 3 and cat 4. There is still a time period between release to the wild and defs being available.

    Also, let's think a little broader than nimda. Let's think about a virus that takes advantage of an IE-based exploit allowing remote code execution. Simply by opening an HTML based email it'll execute. Imagine that the virus does a discovery using domain lookup of all computers. And then it connects to each one, sets the admin password, and emails what it has found to a mail drop. If I'm running as a normal user, computers aren't hit. If I'm running as domain admin, my infrastructure just got rooted.

    K. Brian Kelley
    @kbriankelley

  • I saw a great documentary on traffic safety a while back and what I loved about it was that they hammered home a point I've been telling people about for a long time.  Basically it's this: Safety features do not make things safer. 

    In the auto world, the introduction of anti-lock breaks and airbags, etc. have not reduced traffic fatalities.  The reason is that it is human nature to subconsciously alter your behavior due to the belief that you have a safety net.  For example, those with anti-lock brakes tend to drive a little faster and follow cars a little more closely knowing they have these features, and that behavior offsets the safety factor. 

    One great quote was from an engineer who said that if your purpose was to reduce fatalities on the road, the one simple feature you could add to all cars was a twelve inch, steel spike in the center of the steering wheel pointed directly at your face.  The more danger you perceive, the more attention you will put into being safe.

    So, hell yes.  I say if you're an admin do everything as SA.  The only time I've ever screwed up is in a place where they had me use two different accounts.

    (Do I have to say that an app should never use SA?)

     

  • There is a difference, though, when talking about the Windows world. For instance, the HTML-based email I receive in Outlook. Because of the fact that Microsoft uses the Internet Explorer components, a weakness in IE translates into a weakness in Outlook. So though I may do everything right with respect to how I handle my emails, one bad one can tank not just me, but my environment.

    A better analogy for the Windows world is the circuit breaker. If too much comes over the line than what is expected, that circuit breaker is going to trip in order to try and protect what's on the circuit. Chances are its not something I caused. But I'm still protected. That means the circuit breaker may prevent an electrical fire I had no other means of stopping. However, if I take gasoline and spread it over my house and set fire to it, that's my own fault.

    Running with two accounts works the same way. Reading emails with normal privs may stop an infestation or exploit that could happen had I read the same email with domain admin privs.

    K. Brian Kelley
    @kbriankelley

  • But now you're talking about a different beast.  The security flaw which is microsoft. Meaning Outlook, IE, etc.

    The security hole which is Outlook et. al. is not addressed by not using SA to get into sql server.  And this goes back to my point.  If you are in an environment where using these applications pose a threat, the threat is not mitigated by tweaking how you interact with SQL server.  In fact the threat goes up if you think you have addressed the problem by changing how you interact with SQL Server to make it easier for you to use the bells and whistles of the browser, email, etc.

     

  • Just after I post, the perfect analogy comes to mind:

    If your problem is that you choose to keep a wolf in your sheep pen it is a silly solution to try to fashion chainmail shirts/collars for all of your sheep to stop the loss of sheep. 

  • Not disagreeing with you about sa. My original post indicated DBAs, per se, may be okay (although a virus attacking using Windows auth if the Windows account has sa privs is a different story). I was speaking in general. When you have privileges that can affect the environment in a significant way, then the second account should be considered. It's no different than logging into a *nix system and having to su and type a password to gain root-level access. Yes, it's a pain for the administrator. However, does the risk outweigh the cost. If one runs with domain admin rights, it very well might be worth it to consider two accounts. If you use Windows auth to connect to SQL Server and your account is a member of the sysadmin fixed server role, again, the risk may outweight the cost.

    K. Brian Kelley
    @kbriankelley

  • For myself, in my last job at a major installation I was both DBA and one of the three sysadmins.  I had two PCs with a KVM switch, one was always logged on as admin, one not.  Admin one had no email access and could not access the internet.  This was simply a defensive measure because of the proliferation of email nastiness and seemed the best solution.

    That was around 1999/2001 in an NT4/Win2K environment.  And the admin machine wasn't very beefy, but it was adequate for what it needed to do.  There was never a problem downloading patches using our user account then applying them through our admin account.

    These days, I'd say it depends entirely on the company and your role within.  I never had a problem with the two-system setup, but I made sure to know which one I was on at a given time by having radically different backgrounds and color themes.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply