Bear Giles wrote:
> > the pserver code, which includes setuid currently... Aiyiyi...
>
> Um.... Few applications still switch to root and then stay there.
> It's far more common for the code which requires root access to
> be bracketed by setreuid(root)/setreuid(user). Also, if they only
> need root access for manipulating the filesystem they'll use
> setfsuid() then drop the rest of the privileges.
That's not what I meant. Again, I don't have a whole lot of direct experience
here, but I'm told, and watching RedHat & Ximian errata and other application
specific patches bears this out, that quite a few systems aren't very good about
letting processes drop their root privileges permanently after a setuid call. In
other words, even though the application `setuid's to some "safe" user, it could
easily gain root privileges back again with another call to setuid. Thus a simple
buffer overflow bug which can be exploited to execute arbitrary code can be used to
regain the process' root privileges and thus root access to the system. The only
"safe" way to drop root privileges is to setuid and execute a child process with
the new privileges. If the app which has root privileges & `setuid's is relatively
small it is in theory easier to audit and less likely to have exploitable buffer
overflow bugs.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I will return the seeing-eye dog.
I will return the seeing-eye dog.
I will return the seeing-eye dog...
- Bart Simpson on chalkboard, _The Simpsons_
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
