<div style="margin-left: 40px;"><br></div>On Wed, Feb 16, 2011 at 6:59 PM, Adam Skutt <<a href="mailto:askutt@gmail.com">askutt@gmail.com</a>> wrote:<br>> On Feb 16, 9:00 pm, Dan Stromberg <<a href="mailto:drsali...@gmail.com">drsali...@gmail.com</a>> wrote:<br>
>> So yeah, whether you use perl or anything else invoked with #!, you're<br>>> pretty much better off with sudo, or a tiny C wrapper that's so simple<br>>> it's hard to get wrong.<br>><br>
> UNIX makes this almost impossible<br><br>Please give a source that includes justifying detail. Then you have the right to ask me if there are well understood ways around each of the issues identified.<br><br>> unless your wrapper is cooperative<br>
> with whatever process invokes it<br><br>Isn't this what we were discussing? I know I was. Other than you and I both suggesting sudo as an alternative, that is.<br><br>> , which is itself a security risk. I<br>
> advise anyone seriously considering this route to take a long, hard<br>> look at just what contortions sudo goes through in order to achieve<br>> this safety. A correct suid program is neither tiny nor simple.<br>
<br>Actually, they can be. Here's one, as a very easy-to-find example:<br><br><div style="margin-left: 40px;">$ ls -al<br>cmd started 2011 Wed Feb 16 10:19:21 PM<br>total 8<br>drwxr-xr-x 2 dstromberg dstromberg 4096 2011-02-16 22:19 .<br>
drwxr-xr-x 61 dstromberg dstromberg 4096 2011-02-16 22:18 ..<br>-rwsr-xr-x 1 root dstromberg 0 2011-02-16 22:19 correct-and-simple-setuid<br>benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006 - above cmd done 2011 Wed Feb 16 10:19 PM<br>
<br>$ ./correct-and-simple-setuid<br>cmd started 2011 Wed Feb 16 10:19:24 PM<br>benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006 - above cmd done 2011 Wed Feb 16 10:19 PM<br><br>$ echo $?<br>cmd started 2011 Wed Feb 16 10:19:26 PM<br>
0<br>benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006 - above cmd done 2011 Wed Feb 16 10:19 PM<br></div><br>It's a correct, setuid replacement for /bin/true. It's 0 bytes long. Now, I expect you to exploit it, since I claim that it's both tiny and simple. IOW, it's a reductio ad absurdum.<br>
<br>sudo is an example of something that _isn't_ closely matched with what it's running (beyond a little text in a config file), not something that _is_. You're engaging in a category error there.<br><br>In fact, sudo has a _lot_ of extra complexity to achieve a degree of genericity.<br>
<br>A better example is apache suexec - the helper portion of which is 428 physical SLOC, and it's more complex than most need to be because it keeps many env vars and prunes out others.<br><br>> Passing things through sudo(1) is really the only sensible route these<br>
> days but even that can be fraught with peril.<br><br>Wait - I thought you just said that it was almost impossible unless the setuid wrapper was well matched with the program in question.<br><br>Oh, you did.<br><br>Or was writing sudo almost impossible? Well, no, it may have some expert knowledge built into it, but I believe it was just a mechanical process of translating a surmountable number of bugtraq discussions into code.<br>
<br>> For something as simple<br>> as, 'Write to a normally restricted area' it's probably no more secure<br>> than an ACL (and potentially way less if you screw up the sudo<br>> configuration).<br>
<br>ACL's aren't at all unreasonable, though I believe they'll likely yield a superset of the same problems one would see with a sticky directory. But then, neither are setgid and setuid unreasonable - with setgid being preferred over setuid. <br>
<br>>> However, perl's taint feature would be useful<br>>> irrespective when writing privileged code; it removes some of the<br>>> skill required.<br>><br>> I don't really think so. It doesn't help prevent, for example,<br>
> someone redirecting stdout to /etc/shadow and then running your<br>> command.<br><br>Quantifier error: You've given an example of why taint isn't perfect, not a proof of why it's useless. I said it would be useful, not that it was 100% trouble free.<br>
<br>Moreover, I'd like to see your code demonstrating the ability to make a simple setuid wrapper that doesn't even open a file, append to /etc/shadow. If you'd like, I'll write the wrapper for you.<br><br>
Note that >> is performed by the shell, not the wrapper. If that unprivileged shell (or unprivileged C program, or whatever) can >> /etc/shadow, then you've got bigger problems to worry about.<br><br>Oh, did you mean the _subprogram_ could be exploited? Why didn't you say so? And why is this an attribute of the wrapper, and not an attribute of the subprogram? IOW, you appear to be reasoning that because the _subprogram_ the wrapper invokes /might/ be flawed, the teensy setuid _wrapper_ /definitely/is/inherently/ broken. This, assuming you're really suggesting this, is both a category error and a quantifier error.<br>
<br>> Besides, I'm not even remotely convinced that 'removing<br>> skill' is a good idea.<br><br>Fine. Forget Python. Forget C. Forget assembly language. Forget machine language. Forget firmware programming. Forget plugboards. Forget GUI's. Forget curses. Forget command line. Forget punch cards. Forget toggle switches. In fact, forget electricity where it might remove skill. Since removing skill is a bad idea, I expect that you'll greatly prefer to perform your "coding" using levers and gears, along the lines of the Antikythera mechanism. Then again, maybe you're a little more hardcore than that, and would prefer to forsake automation, forsake handwriting and do your computations strictly in your head.<br>
<br>Reductio ad absurdum again. Sigh.<br><br>> It especially doesn't help you very much when the whole point of your<br>> script is just a wrapper to elevate privileges (execute another<br>> programs) or copy files about.<br>
<br>Did we change the subject again? I'm talking about a C wrapper for a script. Are you talking about a script wrapper for a script? You're confusing me. ^_^<br><br>