[cap-talk] Confused Deputy, multiple authorities - Norm?

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Thu Oct 26 16:57:37 CDT 2006


David Wagner wrote:
> The standard advice in Unix is that the deputy should temporarily switch
> uids to take on the caller's privilege level (e.g., by calling
> seteuid(getuid())) before performing the operation.  This eliminates
> the opportunity for TOCTTOU vulnerabilities.
> 
> Bad (vulnerable to TOCTTOU attacks):
>     if (access(file, W_OK) != 0)
>         return -1;
>     fd = open(file, O_WRONLY);
>     ...
> 
> Good (follows the standard advice):
>     seteuid(getuid());
>     fd = open(file, O_WRONLY);
>     seteuid(0);
> 
> Beware that while the standard advice works for programs that are
> setuid-root, it may be difficult or impossible to implement for programs
> that are setuid to a non-root user (or are setgid).  In general, Unix's
> support for setuid-non-root programs is poor.

The problem here is not just that the standard advice only works for
programs that have root permissions (and would have them anyway); it is
that this kind of advice encourages programs to be run as root when they
would not otherwise be. It is yet another situation (like opening ports < 1024,
and there are many other examples in Unix) where requiring a unnecessarily
strong permission for an operation is counterproductive to security.

Thus the "standard advice" is not good at all -- it is just bad in a
different way.

>>With parameters that confuse it (e.g. command lines too long), buffer 
>>overflows of any sort, etc., etc.  I'm surprised you ask that 
>>question.  If the passwd command can be induced to change a password 
>>other than the user's, then the passwd command has been 
>>"confused".  I believe there have been just such instances of 
>>confusion in the passwd in the past, though I don't have an example 
>>at hand.  Such confusion is certainly possible.
> 
> Please don't use the word "confusion" for this.  You've equated the
> word "confusion" with any and all security vulnerabilities, which just
> eliminated all descriptive meaning in the term.

I agree.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>




More information about the cap-talk mailing list