On Fri, Jul 11, 2008 at 9:31 AM, Natanael Copa <[EMAIL PROTECTED]> wrote:
>> You misunderstood me. I said "If something can be made to use PATH"
>> in a sense "if a program needs to start another program, for God's sake,
>> do NOT hardcode [/usr/][s]bin prefix!" In other words:
>>
>> execve("/bin/vi"...); // BAD
>> execvp("vi"...); // OK
>>
>> Slightly less obvious:
>>
>> char *executable_name;
>> ...
>> execve(executable_name...); // BAD
>> execvp(executable_name...); // OK
>>
>> You won't believe it, but I had hard time convincing people
>> that second form is better in example #2.
>
> That depends. You can make programs do things it was not designed to du
> by tweaking environment variables.
>
> If your app is suid root then you should not use execvp.
>
> create a ~/bin/vi app that does evil things
> PATH=$HOME/bin/vi <program>
>
> if <program> does what you recommend execvp("vi"...) then we have a nice
> privilege elevation bug.
Yes, you are right. I propose to deal with it by sanitizing environment
in setuid apps - which includes setting PATH to "/sbin:/usr/sbin:/bin:/usr/bin".
This is better than "/bin/program" plague, since admin is still free
to place "program" into /bin or /usr/bin. More choices -> good.
(Although now admin lost the ability to "place it in /some/strange/place
and add /some/strange/place to PATH". May be fixable if we can agree
on having /etc/default_PATH_for_suid_programs or something).
Busybox already does env sanitizations in suid programs - see
sanitize_env_if_suid().
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
