On Mon, Aug 12, 2013 at 10:07 AM, Caroline Tice <cmt...@google.com> wrote:
> 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).
SO...I am completely unfamiliar with the "greater lengths in
restricting the logging feature when running SUID/SGID", so I have no
idea what I am supposed to do here. Could you either please elaborate
further, or point me to an example or some documentation? Thank you!
-- Caroline Tice
cmt...@google.com
>
>> 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
