Forgot your password?
typodupeerror
Books Programming Book Reviews

Book Review: Sudo Mastery: User Access Control For Real People 83

Posted by samzenpus
from the read-all-about-it dept.
Saint Aardvark writes "If you're a Unix or Linux sysadmin, you know sudo: it's that command that lets you run single commands as root from your own account, rather than logging in as root. And if you're like me, here's what you know about configuring sudo:

1.) Run sudoedit and uncomment the line that says "%wheel ALL=(ALL) ALL".
2.) Make sure you're in the wheel group.
3.) Profit!

If you're a sysadmin, you need to stop people from shooting themselves in the foot. There should be some way of restricting use, right? Just gotta check out the man page.... And that's where I stopped, every time. I've yet to truly understand Extended Backus-Naur Form, and my eyes would glaze over. And so I'd go back to putting some small number of people in the 'wheel' group, and letting them run sudo, and cleaning up the occasional mess afterward. Fortunately, Michael W. Lucas has written Sudo Mastery: User Access Control for Real People."
Keep reading for the rest of Saint Aardvark's review.
Sudo Mastery: User Access Control For Real People
author Michael W. Lucas
pages 144
publisher Tilted Windmill Press
rating 10/10
reviewer Saint Aardvark
ISBN 1493626205
summary Teaches all there is to know about sudo
If his name sounds familiar, there's a reason for that: he's been cranking out excellent technical books for a long time, on everything from FreeBSD to Cisco routers to DNSSEC. He takes deep, involved subjects that you don't even know you need to know more about, and he makes them understandable. It's a good trick, and we're lucky he's turned his attention to sudo.

The book clocks in at 144 pages (print version), and it's packed with information from start to finish. Lucas starts with the why and how of sudo, explaining why you need to know it and how sudo protects you. He moves on to the syntax; it's kind of a bear at first, but Chapter 2, "sudo and sudoers", takes care of that nicely. Have you locked yourself out of sudo with a poor edit? I have; I've even managed to do it on many machines, all at once, by distributing that edit with CFEngine. Lucas covers this in Chapter 3, "Editing and Testing Sudoers", a chapter that would have saved my butt. By the time you've added a few entries, you're probably ready for Chapter 4, "Lists and Aliases".

sudo has lots of ways to avoid repeating yourself, and I picked up a few tricks from this chapter I didn't know about — including that sudo can run commands as users other than root. Need to restart Tomcat as the tomcat user? There's a sudoers line for that. I'm ashamed to admit that I didn't know this.

There is a lot more in this book, too. You can override sudo defaults for different commands or users. You can stuff sudo directives into LDAP and stop copying files around. You can edit files with sudoedit. You can record people's sudo commands, and play them back using sudoreplay. The list goes on.

Sounds like a lot, doesn't it? It is. But the book flies by, because Lucas is a good writer: he packs a lot of information into the pages while remaining engaging and funny. The anecdotes are informative, the banter is witty, and there's no dry or boring to be found anywhere.

Shortcomings: Maybe you don't like humor in your tech books; if so, you could pass this up, but you'd be missing out. There wasn't an index in the EPUB version I got, which I always miss. Other than that: I'm mad Lucas didn't write this book ten years ago.

You can purchase The Plateau Effect: Getting from Stuck to Success from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Book Review: Sudo Mastery: User Access Control For Real People

Comments Filter:
  • by fph il quozientatore (971015) on Monday February 24, 2014 @02:40PM (#46326225) Homepage
    Please? Can we have it in major distros? Makes a lot of sense from a user's perspective.
    • by EvanED (569694)

      Just make shells recognize postfix commands as arg1 arg2 arg3, cmd (e.g. foo bar, echo will print "foo bar") and then alias it to dammit!

    • I'm not sure that's linguistically appropriate. As a member of the wheel group, you have the authority to demand things of the operating system, but the use of "please", "thank you","you're welcome" serve as reminders of equality. "Please Pass the salt" is a request among equals, that can theoretically be refused, but "Pass the Salt", shorn of its politeness, serves as a command, and an implied threat.
      A better model might be Intercal's use of the PLEASE keyword. While necessary, it loses its usefulness if i

    • by deek (22697)

      I suppose you also want an error message of "You didn't ask nicely", instead of "Permission denied".

      Or, if you use "please" on a noexec mounted filesystem, "Thanks for asking nicely! Permission denied."

  • Not That Bad (Score:5, Insightful)

    by Anrego (830717) * on Monday February 24, 2014 @02:40PM (#46326227)

    I find the sudo config file format confusing and indeed completely ass-backwards, but 30 minutes of googling will give you what like 90% of people using it need to know.

    A book on the subject doesn’t seem like a bad idea though. Sudo probably isn’t going to change much, and sometimes it’s nice to have everything together and consistently presented vice relying on random snippets around the web.

    • by s.petry (762400)

      I find the sudo config file format confusing and indeed completely ass-backwards,

      I don't think you have tried very hard then. The config file format for sudo is about as straight forward as they come. I would hate to hear what you think of named or sendmail macros. Details of sudo are not the same as the config format, and can be confusing. A little trial and error goes a long way, as does using "visudo" so that you can't make a silly syntax error.

      but 30 minutes of googling will give you what like 90% of people using it need to know.

      If you read the man page you would give you the same, or better. I think you touch on a bigger problem though, and that is that people d

  • How much easier can it get than EBNF?

    http://en.wikipedia.org/wiki/E... [wikipedia.org]–Naur_Form

  • and say anyone that doesn't understand EBNF probably doesn't need to be granted SuperUser privilege. If there are specific actions that should be permitted for trusted but unsophisticated users, set up scripts to do only those actions.

    And I'll demonstrate my age by saying that Unix derivatives, including Linux, BSD, etc, etc, -have a long way to go- to match VMS for a truly useful/administrator-friendly privilege model.

  • sudoedit? visudo! (Score:5, Interesting)

    by bartjan (197895) <bartjan AT vrielink DOT net> on Monday February 24, 2014 @02:56PM (#46326383) Homepage

    Using sudoedit to edit the suders file is interesting, but wrong. Please don't do that. Use visudo instead, as it does check for valid syntax.

    Also, what has "The Plateau Effect: Getting from Stuck to Success" to do with sudo?

  • It's come a long way since I pushed it to get published on net.sources. But it still shouldn't need a whole book. Seriously.

  • That you need a whole book on one linux utility?

    • by gonk (20202)

      It scares me that enough people couldn't handle reading a man page that a book was written, if that is what you mean.

      • by benro03 (153441)

        man pages are like Joe Friday, "Just the facts". Dry, boring, and with little to no anecdotes to explain the how and why. I can't count how many times I've run man xyz and ended up Googling the command or emailing a friend to get a better explanation of how to use it.

    • Why not? There are huge books on vi, awk, sed, perl, python, Microsoft Word, postfix, git...
  • If a tool to assign privileges requires 144 manual pages to operate it, it is either broken by design or addressing an audience which won't be able to make secure use of it, anyway.

    In the case of sudo, both may be the case. The sudo config is of absurd anti-ergonomity, and thus broken by design. Plus the average Linux-PC-owner of today is probably not able to oversee the consequences of assigning execution rights for suid executables to ordinary users.

    But sudo is not the only "security threat by obfusca

    • by sexconker (1179573) on Monday February 24, 2014 @03:07PM (#46326513)

      If a tool to assign privileges requires 144 manual pages to operate it, it is either broken by design or addressing an audience which won't be able to make secure use of it, anyway.

      Of fuck off. Assigning privileges in non-trivial scenarios is complex and often non-intuitive, regardless of the tool used to do it.
      A complex system is necessary. A fully-functional/covering tool is necessary. A detailed manual for that tool is a good thing.

      • by benjymouse (756774) on Monday February 24, 2014 @03:48PM (#46326995)

        Not only is the sudoers 144-page-incomprehensible, the whole idea is broken to begin with:

        First, you design a simplistic security model where a single user/group (root) is hardwired to a number of privileges not available to anyone else and where standard users' privileges are inherently too limited.

        Then you start drilling *holes* (big holes) because the model clearly does not meet real world requirements. SUID lets users run as root for the duration of the process. A single escape during the processing will allow the otherwise non-privileged user to drop up to a root shell. A single memory corruption may allow the user to run unrestricted as root. And there has been *many* such exploits in all variants of Unix, including Linux, OS X etc.

        Because the operating system security model did not allow fine grained access control to resources, someone came up with the idea to protect the *utility* instead of the resource or system function (and took out a patent, no less) . WTF? Why does the OS not protect the syscall to change system time or change password? Why did they design a system where you would need to start a frigging SUID root process to do that?

        It is a direct violation of the least privilege principle, one of the core security principles. Every time you let someone invoke sudo you let them run as root and just hope that the utility does not contain vulnerabilities, because the *consequence* of a vulnerability is total system compromise.

        sudo is a design flaw in the ActiveX class. In fact, they are really very much alike: In both cases you hand over the keys to the house and cross your fingers that the visitor is well behaved while he is in there.

        Once the holes have been drilled, sudo (and SUID roots) make it extremely hard for security auditors to assess whether the security has been set up with meaningful barriers: They can not audit a resource and determine who has access to view or change it. The sudo / SUID model always leave the possibility that some utility allows another access to the resource. I.e. the auditor cannot assess a single resource, rather he must assess the system in its entirety. And when doing that he must also trust that the SUID root utilities and sudo utilities are what they pretend to be, i.e. he must validate the utilities as well; or accept the possibility that one or more of the utilities is actually capable of more than it advertises.

        Had the designers opted for a proper model where resources (processes, syscalls, devices, ports) were actually protected by access control lists, the auditor could have audited the security settings and remain confident that there was not some *other* way to access the resource.

        The SUID root / sudo idea was a terrible one. It was necessitated because of an woefully inadequate security model. Rather than fixing the model (like e.g. create real tokens with claims) the designers decided to drill holes. Many holes.

        • Re: (Score:1, Insightful)

          I used to hear this a lot from VMS guys besmirching Unix, though such guys are harder to find these days.

          There's more to life than an abstract security model. Virtual machines are cheap these days, don't let untrusted users (or processes) onto your important server in the first place. If you insist on OS timesharing and full security, well, you're fooling yourself IMHO. Of course VMS could do it, but try to find one now. Not cost effective for the real purpose of getting stuff done, ie, running applicati
          • by rev0lt (1950662)

            There's more to life than an abstract security model.

            Well, its not abstract if it is a short-minded design from the 70's and has caused real concrete problems at least for a decade and a half, and other designs/solutions are available, is it?

            Virtual machines are cheap these days, don't let untrusted users (or processes) onto your important server in the first place.

            They are also not suitable for every workload. They offer no tamper-proofing, the only thing they guarantee is separation of concerns. So lets say you'll use a shared store, with a poorly-chosen (you will only realize this later) user privilege scheme that allows an attacker to wipe out your data. Sure, backups. Now imagi

            • Not buying these exaggerations. Most security vulnerabilities are in the applications themselves, eg buffer overflows, or on the client side. Let's see some evidence where weakness in concern-separation from VMware instances or sudo glitches is a major contributor to malware mishaps these days. I suppose the main vulnerability is a bit less control against insider malfeasance, and those are mostly due to configuration errors or corrupt admins.

              There are architectural reasons to separate, and economic
              • by rev0lt (1950662)

                Most security vulnerabilities are in the applications themselves, eg buffer overflows, or on the client side

                This adds nothing to the discussion. Just like VM's. If you can tamper with data via security vulnerabilities, there is nothing virtualization can do to help you.

                Let's see some evidence where weakness in concern-separation from VMware instances or sudo glitches is a major contributor to malware mishaps these days.

                Well, lets see some evidence that virtualization somehow magically reduces or mitigates security problems, as you suggested. Servers are servers, regardless of the physical infrastructure. If they get compromised, you may be screwed - regardless of it is a logic instance on some blade server or a good ol' physical server.

                I suppose the main vulnerability is a bit less control against insider malfeasance, and those are mostly due to configuration errors or corrupt admins.

                The most common mistake I s

        • by jandrese (485)
          The flipside of this is security systems so complex that regular system administrators have basically no chance of setting them up properly.
          • And we call it SELINUX.

            • by jandrese (485)
              I was going to list Windows ACLs and SELinux as examples, but left them out in the hopes of avoiding fanboy flames from both sides.
          • Yes, that's sounds like the real vulnerability. Whether sudo or fancy role-based access controls or ACLs, these still have to be managed into a useful scenario.
      • by jandrese (485)
        Shoot, if you think sudoers is complex, I have a whole world to show you with Windows ACLs. Ask someone who has been tasked with securing a Windows box and yet still making sure all of its authorized applications work how much they like ACLs. I dare you.
        • by rev0lt (1950662)
          I do prefer the Windows model to the UNIX one. How do you disable the compiler toolchain on a modern system from specific users?
          • by swilly (24960) on Monday February 24, 2014 @08:19PM (#46330119)

            man setfacl

            Linux can use ACLs, they just aren't the default. Simple permissions work most of the time, only use ACLs for those rare occasions where they are needed.

            • by rev0lt (1950662)
              Yeah, sure. So you know every binary your current compiler toolchain has, AND additionally you developed a fancy way for a local user to be forbidden of downloading executable programs. Its one of those things that sound easy to do/use until you have to use them.
    • I don't understand how it is broken by design? 144 pages is fairly short and compact for a security tool. Think about how many endless pages are written about the security tools in Mac or Windows. sudo is a pretty broad tool and its used for a lot of enterprise control. When it comes to the casual user, usually the distro will abstract the tool to a pretty common denominator. Much like Mac and Windows abstract the complex security layers within each of their OSes for the home user.

      I mean seriously, I t

      • It is broken by design because sudo protects the utility used to access the protected resource rather than protecting the resource itself.

        Relying on and allowing such a mechanism does two things to your security model:

        1) It forces users with otherwise legitimate access to go through specific utilities (actually fire up processes) just to access a they should have access to in the first place.

        2) Worse, it takes away your ability to assess who has access to the resource. Since there are multiple SUID root uti

        • Not to diminish your argument, but I believe you're talking about the actual tool while I speak of the configuration of the tool. I think you're argument has some merit but I believe we'd need to rethink the whole way Unix like systems work in general for it to really apply here. I personally feel the manner in which sudo works is quite well, but I understand that some may disagree. However I think it is an entirely different discussion that I doubt that I could argue well sitting in stop and go traffic o
      • by ffkom (3519199)

        I am not saying that Mac or Windows security tools are any better than sudo.

        But I am actually convinced that everything security-relevant, which needs to be dealt with by anyone but its own authors, should have an as-small-as-possible, as-simple-as-possible and easy to comprehend and use interface, because otherwise it will most likely contribute to security disasters, just being mis-used.

        Complexity, flexibility, feature-richness, these are all good attributes of software that is running within the same

        • I totally agree that the current level of abstraction used for things like sudo leaves a lot to desire and that going all out with the man page is a bit over kill for lesser activities. However I would say that is the job of the distro and not the tool's job. But I can see the argument for the converse as well. With that then, I would say that we will just have to disagree as to who's job it is to make something user friendly, because the tool is used in many systems so the tool programmers have to hit a w
      • by ras (84108)

        144 pages is fairly short and compact for a security tool.

        It's a pretty dumb security tool. It allows you become user X if based on a few simple credentials. In fact I can list them: your user, your group, the computer you are on and the program you are running. On top of that, you can ask it to do a few things when to assume user X's credentials like clear the environment, close a few files, log something - nothing you could not also do by running a wrapper script.

        That's it. It's not much. To configur

  • This part got my attention: "Just gotta check out the man page.... And that's where I stopped, every time. I've yet to truly understand Extended Backus-Naur Form, and my eyes would glaze over." - Finally! I'm not the only one! I've always had this problem too. At least now I know what it's called. The formatting used has never made sense to me. Thankfully, we have the internet where I can google examples when trying to learn a new command.

    • I should clarify that I've never understood it because I've never seen it named or defined so i've been trying to figure them out on my own. At least now I know what it's called and I can find some literature on it.

  • by jeffmeden (135043) on Monday February 24, 2014 @03:07PM (#46326509) Homepage Journal

    The book was really great, sounds good, lets check it out:

    "You can purchase The Plateau Effect: Getting from Stuck to Success from amazon.com. Slashdot welcomes..."

    Wait what the fuck book is that?

    (yes the actual link destination is OK, but seriously editors you had _one_ _job_.)

  • Sudo Mastery: User Access Control For Real People

    I really need this. Whenever I say

    sudo make me a sandwich

    I never get any food. And using it in bed! Let's just draw a curtain over that!

    So, I am convinced I need help with using access control on real people. Maybe this book would be just the thing

    http://xkcd.com/149/ [xkcd.com]

  • by Saint Aardvark (159009) on Monday February 24, 2014 @03:30PM (#46326797) Homepage Journal

    Hi all -- I submitted this review, but it looks like something ate the link for the book. Here's where to buy it:

    I believe the Amazon link gives the author a few more shekels, but he makes the most money from the first link; details from his website's page on this book. [michaelwlucas.com]

  • What's so hard about EBNF?

    It seems pretty simple to me.

  • Come on, we all know how we *really* use sudo:

    - Set yourself up with the NOPASSWD option in sudoers
    - sudo su -

    • by neurovish (315867)

      I always get a bit of a laugh when an email comes through that a user tried to sudo su. Fortunately they haven't figured out the trick of using one of the programs with a shell escape, or even sudo bash.

      The scary bit is when the audit trail just disappears or they don't followup with an email asking for something.

  • by Anonymous Coward

    My advice is to open two shells, and visudo in one and test changes in the other. Without closing your editor, save you changes, then go to your other shell and test them. I've had too many times when I had to ask my sysadmin to fix my system for me after I saved my changes and quit without discovering that I removed my priveleges (thus keeping me from being able to undo my mistake). It's like locking your keys in your car, and having to call a locksmith.

    • I've used the same technique when editing /etc/fstab. In one shell, I make may changes and save, without exiting, then use mount -a in the other to see what happens. If there's no output, fine; if there is, I simply go back to the other shell, correct whatever I did wrong, save and try again. Works great for editing any config file that can be easily tested.
      • by Culture20 (968837)
        I do the same thing with iptables. I leave one ssh session open to the server while I restart iptables with the oth%6mg34tk0omEabg9ve^mnPa#+++NO CARRIER+++
  • sudo su (Score:2, Redundant)

    by bzipitidoo (647217)
    No need for sudo fu when you can sudo su!
  • I'm honestly a bit surprised that no one here has mentioned tools that let you manage things like Sudo rules. I highly recommend a project called FreeIPA, think of it as (horrors) AD for Linux/*nix systems. It can join AD forests, enable kerberos SSO across your org. It provides a nice WWW UI (and if that doesn't suit you, a CLI). It can manage sudo/SELInux Policy/NFS automounts/DNS/HBAC and much much more. When combined (default) with SSSD, it can cache auth creds, sudo rules etc etc... It *rea

<<<<< EVACUATION ROUTE <<<<<

Working...