Root access with python

[Jim Dennis]

In article <Ou4o8.17920$Ii4.1702 at atlpnn01.usenetserver.com>, Steve Holden wrote:
>"Andy Gimblett" <gimbo at ftech.net> wrote in message
>news:mailman.1017071438.28406.python-list at python.org...

>> On Mon, Mar 25, 2002 at 12:38:55PM -0300, Gustavo Niemeyer wrote:

>>> You have several options to do this, and all of them involve setting the
>>> setuid bit in some executable. OTOH, setting setuid bit on scripts
>>> usually doesn't work. If that's your case, you'll have to freeze your
>>> script into a native executable, or build some kind of wrapper. Google
>>> for "setuid bit scripts" for more information.

>> As a general solution to this kind of problem, sudo is excellent,
>> though it might be overkill for this particular case.

> The problem is that sudo also required you to authenticate yourself
> periodically, albeit as an ordinary user rather than root. I suppose there
> may be an option to not require authentication, but any such device is
> theoretically dangerous.

> As far as setuid scripts goes, just say no. There are far too many security
> holes in almost every Unix to think that it's safe to use setuid scripts.

> regards
> Steve

  sudo has a "NOPASSWD" modifier that can be selectively added
  to the /etc/sudoers file to allow specific users or groups 
  to execute specific commands (with some controls over acceptable
  arguments) without performing any authentication.

  Naturally this option is necessary for cron jobs and the like.

  As for your overall "advice."  It's of little value to tell
  someone: "don't do that" without offering any suggestion about
  what he or she SHOULD try.

  Whenever discussing computer system security I avoid 
  proscriptive pronouncements like: "you can't do that" or 
  "no one should ..."

  I start with my definition of "security" (the enforcement of
  policy) and I ask: what are the policies that need to be enforced.
  (Policies are requirements that relate of the confidentiality, 
  availability and/or integrity of any resource or resources).  From 
  there I look at possible measures (actions taken or techniques
  employed to prevent, detect or recover from security violations).
  Finally, I select the measures that make sense (where the estimated 
  level of risk mitigation is proportional to the cost and effort).

  However, when we recognize policies as just a subset of requirements
  we also realize that conflicting requirements need resolution.
  So, the OP has one stated requirement (that his or her CGI script
  be able to run, including a particular requirement that it run
  some particular privileged operation).  We (in our responses) are
  inferring a set of *implicit* additional requirements (that the 
  program should not be vulnerable to subversion be otherwise
  exploitable).  

  When we say, "you can't do that," we're imposing requirements on the 
  OP without regard for his or her other requirements and without 
  regard for any risk assessment or cost/benefit analysis that he or
  she may have done.

  Unfortunately I don't know how to make SUID python scripts.  In my
  current ignorance I'd have to recommend sperl with "taint checking,"
  or a sudoers entry, or a small SUID C wrapper program.