Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

samzenpus posted about 5 months ago | from the read-all-about-it dept.

Books 83

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.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.

cancel ×

83 comments

alias please=sudo (2)

fph il quozientatore (971015) | about 5 months ago | (#46326225)

Please? Can we have it in major distros? Makes a lot of sense from a user's perspective.

Re:alias please=sudo (1)

EvanED (569694) | about 5 months ago | (#46326277)

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!

Re:alias please=sudo (1)

Jeremy Erwin (2054) | about 5 months ago | (#46328321)

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 it is overused. Correct programs adhere to formal rules, without being too obsequious.

DO ,1 <- #13
PLEASE DO ,1 SUB #1 <- #238
DO ,1 SUB #2 <- #108
DO ,1 SUB #3 <- #112
DO ,1 SUB #4 <- #0
DO ,1 SUB #5 <- #64
DO ,1 SUB #6 <- #194
DO ,1 SUB #7 <- #48
PLEASE DO ,1 SUB #8 <- #22
DO ,1 SUB #9 <- #248
DO ,1 SUB #10 <- #168
DO ,1 SUB #11 <- #24
DO ,1 SUB #12 <- #16
DO ,1 SUB #13 <- #162
PLEASE READ OUT ,1
PLEASE GIVE UP

Re:alias please=sudo (1)

deek (22697) | about 5 months ago | (#46331173)

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."

simon says (0)

Anonymous Coward | about 5 months ago | (#46342421)

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.

Not That Bad (4, Insightful)

Anrego (830717) | about 5 months ago | (#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.

Re:Not That Bad (1)

s.petry (762400) | about 5 months ago | (#46329211)

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 depend on Google instead of knowledge today. I'm not blaming or accusing, because with some things I behave exactly the same. We simply have to support too much stuff to be an expert in anything today. Google a quick fix does not give a person any real knowledge.

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.

That part I agree with, but remember we are not reading the book to do what 90% of the people do (which is add people to the sudo group in Debian or wheel group in Redhat). I'm not sure he covers it, but I had a nice long write up a long time ago regarding sending X11 displays through sudo. Most users don't, so it's not an issue. We had a vended application that required a display to install, so had to run a display. That was mostly complex because of Xauthority, not sudo.

Seriously? EBNF is hard? (1)

mveloso (325617) | about 5 months ago | (#46326285)

How much easier can it get than EBNF?

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

Re:Seriously? EBNF is hard? (1)

Anonymous Coward | about 5 months ago | (#46326305)

How much easier can it get than EBNF?

Your mom.

Fine, mod it troll. (1)

slack_justyb (862874) | about 5 months ago | (#46326463)

But you have to admit, mveloso walked into that one. :-D

Re: Fine, mod it troll. (0)

Anonymous Coward | about 5 months ago | (#46328763)

His mom was so easy I had to walk into her too.

Re:Seriously? EBNF is hard? (1)

Anrego (830717) | about 5 months ago | (#46326323)

I'd prefer to call it awkward and unwieldy, but yeah, a little time on google and you can probably figure out what you need to do.

Re:Seriously? EBNF is hard? (1)

sexconker (1179573) | about 5 months ago | (#46326399)

Slashdot eated ur link
Slashdot eated ur link
Here is a working link: http://en.wikipedia.org/wiki/E... [wikipedia.org]
Slashdot eated ur link

Too technical for audience (0, Troll)

Anonymous Coward | about 5 months ago | (#46326311)

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.

Re:Too technical for audience (1)

gmuslera (3436) | about 5 months ago | (#46326527)

You can use it for everyday tasks [xkcd.com] too. At least the summary is easier to read than man 5 sudoers.

Re:Too technical for audience (1)

lucm (889690) | about 5 months ago | (#46326535)

#insuling

Re:Too technical for audience (0)

Anonymous Coward | about 5 months ago | (#46326605)

That's probably true. This would probably be better suited for a site like soylentnews.org or over on usenet on comp.misc.

I'm going to be elitist (1)

david.emery (127135) | about 5 months ago | (#46326371)

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.

Re:I'm going to be elitist (0)

Anonymous Coward | about 5 months ago | (#46327285)

Yup: VMS and the CLUG (Command Language User Guide) were the best. All that (clustering, failover. load balancing, networking) in 1978.

sudoedit? visudo! (4, Interesting)

bartjan (197895) | about 5 months ago | (#46326383)

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?

Re:sudoedit? visudo! (0)

Anonymous Coward | about 5 months ago | (#46326835)

My knowledge of vi/vim is minimal enough that I'd be more comfortable editing in nano than with using visudo and risking accidentally putting in some key combination that will set my hard drive on fire.

Re:sudoedit? visudo! (2)

derfy (172944) | about 5 months ago | (#46326921)

visudo will use whatever editor you have defined in the variable 'editor'.

Re:sudoedit? visudo! (0)

Anonymous Coward | about 5 months ago | (#46326989)

Set the environmental variable VISUAL to nano, and then you can use visudo to your heart's content without having to learn vi.

Captcha: Dimming. Yes, Slashdot sure is!

Re:sudoedit? visudo! (2)

andyhhp (1373567) | about 5 months ago | (#46329487)

(wo)man up and set $EDITOR correctly for your environment. You might find visudo more accomodating.

Re:sudoedit? visudo! (1)

Saint Aardvark (159009) | about 5 months ago | (#46326851)

Yeah, they got the link wrong...not sure what happened there.

A book on sudo!? (1)

jlv (5619) | about 5 months ago | (#46326395)

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.

Does it scare anyone else? (1)

MouseTheLuckyDog (2752443) | about 5 months ago | (#46326403)

That you need a whole book on one linux utility?

Re:Does it scare anyone else? (3)

gonk (20202) | about 5 months ago | (#46326931)

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

Re:Does it scare anyone else? (0)

Anonymous Coward | about 5 months ago | (#46327557)

It scares me that people think limiting access to the wheel group limits access to root.

Re:Does it scare anyone else? (1)

benro03 (153441) | about 5 months ago | (#46335167)

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.

Re:Does it scare anyone else? (2)

bluefoxlucid (723572) | about 5 months ago | (#46327213)

Why not? There are huge books on vi, awk, sed, perl, python, Microsoft Word, postfix, git...

Re:Does it scare anyone else? (0)

Anonymous Coward | about 5 months ago | (#46329171)

Personally, I don't need a book to learn a command. It scares me that other people can be tricked into thinking they need a book to learn a command.

p.s. Look for my new books "/bin/dd for Dummies," "/bin/echo for Eggheads," "/usr/bin/less for Losers," and "/bin/more for Morons" in your /. newsfeed later this week!

Is sudo broken or its audience? (1, Interesting)

ffkom (3519199) | about 5 months ago | (#46326409)

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.

Re:Is sudo broken or its audience? (3, Insightful)

sexconker (1179573) | about 5 months ago | (#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.

sudo is broken by design (4, Insightful)

benjymouse (756774) | about 5 months ago | (#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:sudo is broken by design (1, Insightful)

John Da' Baddest (1686670) | about 5 months ago | (#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.

Re:sudo is broken by design (0)

Anonymous Coward | about 5 months ago | (#46328589)

You can break out virtual machines just as easily as you can a SUID utility (and virtual machine exploits will slowly trail off, just as they did with SUID utilities). The fundamental issue is bugs, and no amount of time spent writing ACLs will resolve that problem.

ACLs provide an illusion of security. They make the administrator believe he can paper over flaws in the underlying code with a flurry of aspirational permission statements.

There are two indisputable general principles in software security: 1) simplicity is better, and 2) attention to security issues must be paid at every level.

Both virtual machine and complex ACL-based solutions pretty much lose on both counts. For a better solution, see Capsicum, which is an evolution of the very simple traditional Unix framework.

Re:sudo is broken by design (2)

John Da' Baddest (1686670) | about 5 months ago | (#46329505)

I'm interested to hear about breaking out of one VMware instance and into another, in easy and readily exploitable ways. Not to say it can't happen in some edge cases - but suggesting that it's often trivial is a bit much.

Re:sudo is broken by design (0)

Anonymous Coward | about 5 months ago | (#46422689)

but suggesting that it's often trivial is a bit much.

Oh really, a bit much? If you know nothing about the security hazards of emulating CPUs , or writing secure kernel mode code (which is where VM implementations live) that accounts for *all* of the CPU specification, why are you even commenting? Its rather obvious you know nothing about the way CPU bugs (esp x86) are continuously exploited - be it obscure quirks like the intel x64 sysret vuln where windows and linux both didn't account for an obscure 64bit exception or the intel DR6 vulnerability or the swapgs VMware vulnerability..

"LOL I run code inside a VM.. I'm safe .. lolz.. "

I know this Slashdot where most of the people here are non-technical OSS zealot mouth breathers just repeating some old tired myths and slapping each other on the back, but atleast do a fucking google search ..

Re:sudo is broken by design (1)

rev0lt (1950662) | about 5 months ago | (#46329451)

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 imagine how long does it take to recover out 30TB of data from your backup structure?

If you insist on OS timesharing and full security, well, you're fooling yourself IMHO.

It has nothing to do with timesharing, but separation of concerns. I assume you don't have eg. a single VM for each apache process, and a load balancer in front of it - but that's what you're suggesting. Having eg. mail stuff separated from the crappy php cms is a problem that was solved at least almost decade and a half ago in FreeBSD, and in the remaining Unixes you could always use (buggy) chroot techniques. The problem is, that if someone attacks your server and TAMPERS your data, months may pass before you realize it. And then most (all?) of your backups are tainted. How did a VM helped with that? Right.

Of course VMS could do it, but try to find one now

Still doesn't change the fact that the UNIX security model is broken for modern applications. Its not all bad - Windows has a acl/permission system eons ahead of the traditional Unix, and its not better because of it. But VMs add nothing to the mix - unless you consider application sandboxing "VM's". In that case, have a look at capiscum (FreeBSD) and systrace (OpenBSD).

Re:sudo is broken by design (1)

John Da' Baddest (1686670) | about 5 months ago | (#46329851)

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 & practical reasons to consolidate - or not. I'd say you're off the curve of reasonable expectations if you're asking for mainframe-style "trusted" isolation on a setup of only a few (or just one) PC-grade servers in which you have all applications and services running together along with a variety of login access from different categories of users who may be potential attackers. Not that there's anything wrong with the BSD's etc, but in the scenarios you imply, you might be placing your support resources in areas of lower risk priority. Or maybe you yourself are the single supporter?

I say "PC-grade" because your scenario sounds economically uninteresting -- important enough to protect as you want (with excessive apps & users), but not important enough that there's budget to do hardware separation. Just because you're broke doesn't mean that Unix is broken. I agree that BSD Capsicums (etc) may be a good fit for these outlier use-cases, or special situations, but mostly if your establishment is willing to make a heavy technology investment in going that route.

Re:sudo is broken by design (1)

rev0lt (1950662) | about 5 months ago | (#46330651)

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 see (and I'm not a DevOps, so it may be biased) is authentication - once a single server is compromised, it may be possible to access other servers, due to proliferation of key-based authentication without password. It is a lot harder to properly secure a bunch of isolated servers that somehow work as a single service than a single machine, without sacrificing ease of administration. Good chances are, on a given cluster, all webservers have the same credentials - and this gets even more common when using management tools like puppet or cfengine.

I'd say you're off the curve of reasonable expectations if you're asking for mainframe-style "trusted" isolation on a setup of only a few (or just one) PC-grade servers in which you have all applications and services running together along with a variety of login access from different categories of users who may be potential attackers.

I'm not, You suggested that, with VM. I just pointed out how unrealistic that is - in the real world.

I say "PC-grade" because your scenario sounds economically uninteresting -- important enough to protect as you want (with excessive apps & users), but not important enough that there's budget to do hardware separation.

On the contrary. You were promoting VMs as a tool for security - its not. More often than not, it actually extends the surface of attack. VMs do have huge advantages, not only to consolidate resources, but also as an easy way of providing fault-tolerance and high-availability. Those are some of the key benefits of virtualization. Security is not one of them.

I agree that BSD Capsicums (etc) may be a good fit for these outlier use-cases, or special situations, but mostly if your establishment is willing to make a heavy technology investment in going that route.

the parent thread was about the broken unix security model. Not that some of the available tools on the BSDs would require considerable effort - having an application xyz running on 1 machine/vm or in 10.000 machines/vm is roughly the same thing, from an administrative point of view. I could argue that, academically, Windows has a far superior security model than anything you can find on unix systems, but that would be off-topic. The same way considerations about edge cases and cluster sizes are - its not what is being discussed. VMs add nothing - directly - to the security discussion.

Re:sudo is broken by design (0)

Anonymous Coward | about 5 months ago | (#46327329)

Which is why I don't let sudo run as root. You can use it so that different programs run as different users. It can also be used to downgrade permissions and all sorts of things. Its the administrator using it as a sledgehammer with the %wheel ALL=(ALL) ALL command that ruins it.

Re:sudo is broken by design (1)

jandrese (485) | about 5 months ago | (#46327453)

The flipside of this is security systems so complex that regular system administrators have basically no chance of setting them up properly.

Re:sudo is broken by design (2)

SuricouRaven (1897204) | about 5 months ago | (#46327627)

And we call it SELINUX.

Re:sudo is broken by design (1)

jandrese (485) | about 5 months ago | (#46327961)

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.

Re:sudo is broken by design (1)

John Da' Baddest (1686670) | about 5 months ago | (#46331987)

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.

Re:Is sudo broken or its audience? (2)

jandrese (485) | about 5 months ago | (#46327411)

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.

Re:Is sudo broken or its audience? (1)

rev0lt (1950662) | about 5 months ago | (#46329479)

I do prefer the Windows model to the UNIX one. How do you disable the compiler toolchain on a modern system from specific users?

Re:Is sudo broken or its audience? (3, Insightful)

swilly (24960) | about 5 months ago | (#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.

Re:Is sudo broken or its audience? (1)

rev0lt (1950662) | about 5 months ago | (#46330719)

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.

Re:Is sudo broken or its audience? (1)

slack_justyb (862874) | about 5 months ago | (#46326927)

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 think someone is missing the point here. That 144 page manual is for someone who is sitting in an admin chair, who will need to properly craft the file so that a central Unix/Linux box is properly maintained. I know MCSEs that have read tomes of information related to Windows security and I'm pretty sure the same holds true for Mac people as well.

This is my take on your comment, and if I'm wrong on this feel free to catch me on that. You are expecting home users to read something that is more geared for admins. Maybe even small time admins to read that, when usually the default out-of-box is good enough for a 10~50 employee setup. The question being now, "Would you expect a home user or a small time admin to be up to the same level, when it comes to security, as say an MCSE?" I don't think so and likewise, the sudo man page (and also PAM and dbus) is mostly geared for your high level admins who are going to need to know that kind of stuff.

So I don't think it is broken by design because it works as intended for the audience that it was geared for. For the home user and small business, if the default sudoers, pam.d/*, or dbus.conf isn't secure, that's mostly a problem with the distro makers and poor choice for their target audience. Not a sign that users need to read 600+ pages of manual. Overall, ask any admin of any OS how many pages it would take them to completely describe a tool like sudo for their OS and I'm pretty sure you'll find that 144 pages is on the low end of that scale.

Re:Is sudo broken or its audience? (2)

benjymouse (756774) | about 5 months ago | (#46327159)

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 utilities on the system, and multiple sudo utilities with sudoers config, you really have to know the capabilities of each of those utilities to know that they cannot be used by an unauthorized user to access the protected resource.

Had you used a system where the resource was protected and where there were no sudo/SUID bypass mechanism available, you can generate a report of users with access to the resource simply by querying the user/group permissions. As an added benefit, anyone with legitimate access could then access the resource and not be forced fire up a process and to go through a specific utility to access the resource.

Re: Is sudo broken or its audience? (0)

slack_justyb (862874) | about 5 months ago | (#46327489)

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 on my phone. So I'll have to apologize if I bow out of this discussion for the time being. Maybe later today I can get back with you because I think the topic you bring up is incredibly fascinating.

Re: Is sudo broken or its audience? (0)

Anonymous Coward | about 5 months ago | (#46422777)

weasel words..
"i belive"
"i personally feel"
"some may"
blah blah

Its rather obvious you don't have the technical chops to argue his point. Sit down, boy..

Re:Is sudo broken or its audience? (2)

ffkom (3519199) | about 5 months ago | (#46327311)

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 security context of one certain user.

But security tools that pass the boundaries of one security context are so delicate and so difficult to secure against introducing security holes of their own, that they should be simple, non-flexible, with the smallest feature set required.

You are expecting home users to read something that is more geared for admins.

If sudo is geared only for professional admins, then its man-page should be sufficient, no need for a book.

But even then, it would not harm to have a less user-unfriendly config file format. Just look how well the postfix config files work - in comparison to the sendmail config, which suffers from ergonomic deficits not unlike those of sudo.

Re: Is sudo broken or its audience? (1)

slack_justyb (862874) | about 5 months ago | (#46327567)

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 wide target. Distro makers know their audience and should aim for that target.

Re:Is sudo broken or its audience? (1)

ras (84108) | about 5 months ago | (#46329967)

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 configure this relatively simple thing the author invented this god awful syntax. It's one virtue is it's compactness - so it's forgivable I suppose, particularly if he writes a clear man page readable by humans. But he didn't. He used EBNF. Now let me tell you, as a person who has written parser generators, an inevitable fact about any non-trivial grammar. When first written they are full of bugs. It's hardly surprising given they are regular expressions on steroids, and most people struggle to get just one non-trivial regular expression right - and an EBNF is a list of them. Thus even the person writing them can not predict the language they will recognise. The only way to get rid of the bugs is to compile a parser from them, test it on various language constructs, then fix the surprises.

You can take it from that EBNF is a great way to express things so a computer will understand it. But not so good for a human. If you are expecting someone to write a computer program to match the grammar, it might be a reasonable choice. If you are using it in a man page that only humans will read it's a bloody awful choice. Maybe it might be justifiable if he just ripped the grammar straight out of his source code. At least we could be sure it was right them. But he didn't. The source doesn't use a grammar at all.

But then if the grammar in the man page has never been compiled or tested, and given it is non-trival, then if what I said above is true it won't recognise the sudo config file. And it doesn't. For instance, nowhere in the grammar does it express all commands must lie on a single line. In fact he doesn't even mention it directly the text either, beyond saying at the end you can split long lines using a \. You are meant to infer it from the examples I guess.

So to sum up, we have a simple concepts expressed in a terse and complex configuration language, which is described by a an untested EBNF so complex it needs it's own syntax description in the man page, and we know the EBNF is incomplete. That is why the sudo man page is a cluster fuck. It has nothing to do with your "oh security is complex" throw away line.

And does it need a 144 page book to explain it? No, of course not. A man page about the size of the one we have could get all the concepts across just fine.

No sudo allowed here (0)

Anonymous Coward | about 5 months ago | (#46326439)

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.

Script Much? (1)

psyclone (187154) | about 5 months ago | (#46328377)

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

#! script:
# backup deployed app...
sudo /sbin/service app stop
# deploy app...
sudo /sbin/service app start
# return whatever

Sounds like an interesting read. (1)

scottbomb (1290580) | about 5 months ago | (#46326457)

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.

Re:Sounds like an interesting read. (1)

scottbomb (1290580) | about 5 months ago | (#46329313)

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.

A good book huh (2)

jeffmeden (135043) | about 5 months ago | (#46326509)

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_.)

144 pages (0)

Anonymous Coward | about 5 months ago | (#46326585)

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.

Re:144 pages (0)

Anonymous Coward | about 5 months ago | (#46326805)

Are you newfags incapable of responding to the post rather than posting under it?

Re:144 pages (0)

rwa2 (4391) | about 5 months ago | (#46326935)

Oh, just make it more like Windows and use
* ALL=ALL:NOPASSWD
already! :-D

Then you can set up passwordless ssh with no passphrase to all your systems do stuff like
for H in `cat myhosts.txt` ; do ssh -qt $H "sudo rm -rf /" > $H.txt & done

A book I need (0)

mbone (558574) | about 5 months ago | (#46326687)

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]

Correct link for buying the book (4, Informative)

Saint Aardvark (159009) | about 5 months ago | (#46326797)

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]

EBNF? (1)

TechyImmigrant (175943) | about 5 months ago | (#46326849)

What's so hard about EBNF?

It seems pretty simple to me.

NOPASSWD and su - (1)

Vrallis (33290) | about 5 months ago | (#46326881)

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

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

Re:NOPASSWD and su - (0)

Anonymous Coward | about 5 months ago | (#46327133)

I work at a company where the IT team has an insanely stupid and complex sudo configuration mirrored on all the systems. Because it's such a headache (including requiring you to enter your user password, which the Exchange administrators make us change every 3 months), everybody just logs in as root using the same password the company has used for like the past 10 years. Go figure.

There's nothing more dangerous than an IT administrator wielding a configuration manual. He instantly forgets the more important principle in security--K.I.S.S.

I refuse to participate in these crimes against network security, and fortunately I have the tenure to get away with it. I have a secure hardware token which authenticates my SSH sessions to company servers (at least those which support authorized_keys files), and I use /dev/urandom to generate a 12 character password for corporate e-mail and IM. If I need root for something, I'll develop it on my own personal servers (or maybe just my mac laptop) and have some other engineer deal with getting it to work on our network, rather than having to copy+paste my 12 character password every two minutes, generating an easily crackable password which is more convenient to enter, or working as root.

Security and convenience are not a trade-off. You just have to put in effort to finding those solutions which maximize both. But most people can't be bothered, so they err either on the side of convenience or on the side of security; and my work environment is an insanely comical example, but sadly quite typical.

Re:NOPASSWD and su - (1)

neurovish (315867) | about 5 months ago | (#46328061)

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.

Sudo for trusted root access only (0)

Anonymous Coward | about 5 months ago | (#46326909)

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.

I'll tell you what NOT to do (1)

Anonymous Coward | about 5 months ago | (#46326971)

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.

Re:I'll tell you what NOT to do (0)

Anonymous Coward | about 5 months ago | (#46327243)

Maybe your sysadmin is the one who should be using visudo in the first place.

Re:I'll tell you what NOT to do (1)

techno-vampire (666512) | about 5 months ago | (#46328111)

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.

Re:I'll tell you what NOT to do (2)

Culture20 (968837) | about 5 months ago | (#46329369)

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+++

Hang on... I know this one (0)

Anonymous Coward | about 5 months ago | (#46327551)

sudo rm -rf /beta/

sudo su (1, Redundant)

bzipitidoo (647217) | about 5 months ago | (#46327889)

No need for sudo fu when you can sudo su!

sudo vim /etc/httpd.conf (0)

Anonymous Coward | about 5 months ago | (#46328899)

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.

Why complicate things? (0)

Anonymous Coward | about 5 months ago | (#46329201)

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.

FreeIPA (1)

IMightB (533307) | about 5 months ago | (#46337549)

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

The book is great. (0)

Anonymous Coward | about 4 months ago | (#46439335)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...