[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dropping setuid/setgid privileges

From: Bruno Haible
Subject: Re: dropping setuid/setgid privileges
Date: Tue, 9 Jun 2009 11:07:08 +0200
User-agent: KMail/1.9.9

Sam Steingold wrote:
> > If I did this, the risk that a bug does not get reported would be too
> down with the nannies!
> let us assume that I threw in the anti-totalitarian-programming
> diatribe here. :-)

I call it collaborative programming: I program something, and users report
bugs, until the code gets better. :-)

> > high. For the average user, abort() is acceptable. (Note the module
> > is not suitable for use in libraries.)
> then it is not suitable for clisp either.
> you could easily make it suitable for libraries too by returning an
> exit code

The point is not the return code. It's about the amount of things that
you have to check in order to be sure that you are not distributing a
security vulnerability.

For the idpriv-drop module the doc says (thanks James!):

      Note: There may still be security issues if the privileged task puts
      sensitive data into the process memory or opens communication channels
      to restricted facilities.

For the idpriv-droptemp module it's even worse:

    there are additionally the dangers that
     - Any bug in the non-privileged part of the program may be used to
       create invalid data structures that will trigger security
       vulnerabilities in the privileged part of the program.
     - Code execution exploits in the non-privileged part of the program may
       be used to invoke the function that restores high privileges and then
       execute additional arbitrary code.

In the situation of a library you cannot foresee, not even check, the
possible interactions of the sensitive data structures and the code outside -
because by definition, the code outside is not limited to your source

That's why these two modules make sense only in executables, and the second
one only in *small* executables which you completely overlook.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]