Slashdot Mirror
Book Review: Sudo Mastery: User Access Control For Real People
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.
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.
Please? Can we have it in major distros? Makes a lot of sense from a user's perspective.
My first program:
Hell Segmentation fault
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.
How much easier can it get than EBNF?
http://en.wikipedia.org/wiki/E...–Naur_Form
Come on Slashington this is way too technical for the audience here. The programmers and nerds left long ago. Just roll out your shitty Beta, only post tech news along with your shallow stock images and be done with it. Stop posting this shit its insuling.
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.
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?
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 obfuscated design". Just quiz people on how PAM or dbus actually control access rights, ask them where they would find or change the configuration that allows user X to to Y by the way of PAM or dbus, and you'll see that almost no one besides the authors can answer.
just strictly controlled root access to the three people that need it. No exceptions ever.
root password changes daily.
Want root access? Raise a ticket with the justification. Unless it is during a scheduled downtime period access is limited to 1 hour.
All logged and auditable.
I know that some /.'er will justify using sudo over proper root access but choice is one of the great things about Open Source. Use whatever works for you and your setup.
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.
But you have to admit, mveloso walked into that one. :-D
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_.)
if you think 144 pages is too much.. then you're in the wrong field.. sudo i very powerful and gives you the ability to be very granular. The sudo command is far from broken, as a UNIX sys admin I use sudo in my daily life and have tied it with LDAP. Just because your sudo configs prolly read ALL: ALL ... doesnt make it right. In any UNIX system, you configure the app to your needs.
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/
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.
Carousel is a lie!
What's so hard about EBNF?
It seems pretty simple to me.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Come on, we all know how we *really* use sudo:
- Set yourself up with the NOPASSWD option in sudoers
- sudo su -
Sudo is great when you trust people invoking it, and want to avoid accidental disaster. Not so good for when there is a chance of malicious users. For that, Access Control Lists must be used.
Not a dig against sudo, a great tool for what it does.
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.
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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
sudo rm -rf /beta/
No need for sudo fu when you can sudo su!
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I guess you never have a user ssh in (via keys) and run a script, like to deploy an application:
.... NOPASSWD: /sbin/service app start, /sbin/service app stop
/sbin/service app stop /sbin/service app start
#! script:
# backup deployed app...
sudo
# deploy app...
sudo
# return whatever
I have seen this a lot: an admin givinig me the above sudo to be able to edit a config file. And he actually believed that was secure. Never heard of vim's ! shell escape. Never imagined that I could load a custom root shell apache module.
Sudo makes any security disaster look very secure.
user: Hey, I need to do a couple of things as root
me: no
user: but I need to do it to do my job
me: too bad
user: my manager needs me to do this
me: then have him come to me
manager: why won't you let Jim be root?
me: because I don't allow it
manager: well then let me do it
me: no
manager: this is mission critical and requires root access
me: no, it isn't, and no, it doesn't. Find another way to solve your problem
*click*
See? No security issues.
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 *really* is a nice project and is probably at the forefront of modern OSS *nix authentication systems.
Editing /etc/sudoers manually is so 1990's
I think it should be "simon says." Then, when you attempt to do something which requires sudo, the error message is to the effect of "you didn't say 'simon says.'"
Then perhaps it'd be obvious enough what a pile of BS the whole idea is and our distributions would start doing by default what I do with every install I make: immediately change my user's ID to 0 and symlink his home folder to /root. The symlink is required because some software uses your HOME environment variable while other software finds your UID and looks it up in /etc/passwd and so you end up with different home folders depending on which software you're using. Other than that, it works like a charm, short of a couple of pieces of software which look at the UID of 0 and decide to be bitches about it and refuse to run.
The whole concept of protecting users from themselves is bullshit anyway. First of all, the most important thing to a user are his personal files, not the fucking OS which he can simply re-download from the internet, and sudo does nothing to prevent a user from deleting all of his personal files. Secondly, damn near all of us are the only users of our computers anyway, and so we're just torturing ourselves with a game of "simon says" every time we try to do something as trivial as change the system time rather than protecting our computers from anything. Third, it isn't shit like "not running as administrator" that protects Linux computers -- the vast majority of malware would be just as happy to own a user account as it would be to own the entire system, and while not running as administrator would make it easier for antivirus software to detect malware, Linux has no antivirus software and so that's a moot point -- what protects Linux is shit like loading libraries at random addresses so that it isn't so easy to exploit buffer overflows, and other technical solutions like that which don't interfere with the user in any way at all. So we don't need sudo at all. If it's your computer, just run as root, and enjoy the simpler life that creates for you.
i bought the book based on this forum. Permissions and sudo weren't my strengths and I wanted learn more. And more I did! I know a lot of slashdot "experts" made fun but sudo really does add an extra layer of security and system understanding that I craved. Thank you for bringing this book to my attention.
Regards,
A.B.