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:
  • Not That Bad (Score:5, Insightful)

    by Anrego (830717) * on Monday February 24, 2014 @03: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 sexconker (1179573) on Monday February 24, 2014 @04: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 @04: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.

  • by John Da' Baddest (1686670) on Monday February 24, 2014 @05:06PM (#46327223)
    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 applications.
  • by swilly (24960) on Monday February 24, 2014 @09: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.

I'd rather just believe that it's done by little elves running around.

Working...