Best way to gain root privileges

[Dan Stromberg]

On Wed, Feb 16, 2011 at 6:59 PM, Adam Skutt <askutt at gmail.com> wrote:
> On Feb 16, 9:00 pm, Dan Stromberg <drsali... at gmail.com> wrote:
>> So yeah, whether you use perl or anything else invoked with #!, you're
>> pretty much better off with sudo, or a tiny C wrapper that's so simple
>> it's hard to get wrong.
>
> UNIX makes this almost impossible

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.

> unless your wrapper is cooperative
> with whatever process invokes it

Isn't this what we were discussing?  I know I was.  Other than you and I
both suggesting sudo as an alternative, that is.

> , which is itself a security risk.  I
> advise anyone seriously considering this route to take a long, hard
> look at just what contortions sudo goes through in order to achieve
> this safety.  A correct suid program is neither tiny nor simple.

Actually, they can be.  Here's one, as a very easy-to-find example:

$ ls -al
cmd started 2011 Wed Feb 16 10:19:21 PM
total 8
drwxr-xr-x  2 dstromberg dstromberg 4096 2011-02-16 22:19 .
drwxr-xr-x 61 dstromberg dstromberg 4096 2011-02-16 22:18 ..
-rwsr-xr-x  1 root       dstromberg    0 2011-02-16 22:19
correct-and-simple-setuid
benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006
- above cmd done 2011 Wed Feb 16 10:19 PM

$ ./correct-and-simple-setuid
cmd started 2011 Wed Feb 16 10:19:24 PM
benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006
- above cmd done 2011 Wed Feb 16 10:19 PM

$ echo $?
cmd started 2011 Wed Feb 16 10:19:26 PM
0
benchbox-dstromberg:~/src/correct-and-simple-setuid i686-pc-linux-gnu 12006
- above cmd done 2011 Wed Feb 16 10:19 PM

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.

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.

In fact, sudo has a _lot_ of extra complexity to achieve a degree of
genericity.

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.

> Passing things through sudo(1) is really the only sensible route these
> days but even that can be fraught with peril.

Wait - I thought you just said that it was almost impossible unless the
setuid wrapper was well matched with the program in question.

Oh, you did.

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.

>  For something as simple
> as, 'Write to a normally restricted area' it's probably no more secure
> than an ACL (and potentially way less if you screw up the sudo
> configuration).

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.

>> However, perl's taint feature would be useful
>> irrespective when writing privileged code; it removes some of the
>> skill required.
>
> I don't really think so.  It doesn't help prevent, for example,
> someone redirecting stdout to /etc/shadow and then running your
> command.

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.

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.

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.

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.

>  Besides, I'm not even remotely convinced that 'removing
> skill' is a good idea.

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.

Reductio ad absurdum again.  Sigh.

> It especially doesn't help you very much when the whole point of your
> script is just a wrapper to elevate privileges (execute another
> programs) or copy files about.

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.  ^_^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110216/b6e39cd5/attachment.html>