On Mon, Aug 12, 2013 at 4:15 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 08/12/2013 12:39 AM, Caroline Tice wrote:
>>
>> On Sun, Aug 11, 2013 at 1:04 PM, Florian Weimer <fwei...@redhat.com>
>> wrote:
>>>
>>> On 08/11/2013 01:08 AM, Caroline Tice wrote:
>>>>
>>>>
>>>> OK, I have removed the attempt to use $HOME for the logs; they will
>>>> now either go into the directory specified by the environment variable
>>>> VTV_LOGS_DIR, or they will go into the current directory. I also
>>>> added code to use secure_getenv, rather than getenv, if it is
>>>> available. Is this patch ok to commit?
>>>
>>>
>>>
>>> + logs_prefix = secure_getenv ("VTV_LOGS_DIR");
>>> + if (!logs_prefix || strlen (logs_prefix) == 0)
>>> + logs_prefix = (char *) ".";
>>>
>>> Hmm. If you fall back to the current directory, using secure_getenv
>>> doesn't
>>> have the intended security effect. I wonder if we can simply label this
>>> functionality as unsafe for SUID/SGID programs, like we (hopefully) do
>>> for
>>> profiling.
>>>
>>
>> I am unclear how to do this? Could you elaborate please?
>
>
> I think it boils whether vtv is a debugging feature (like mudflap or
> profiling), or supposed to be active in production code (like the stack
> protector). If the latter, we have to go to greater lengths in restricting
> the logging feature when running SUID/SGID.
>
The feature is supposed to be active in production code (like the
stack protector).
> Looks like we lost the Cc: to gcc-patches. Not sure if this is intentional.
> Feel free to add it again.
Done.
-- Caroline Tice
cmt...@google.com
>
>
> --
> Florian Weimer / Red Hat Product Security Team
