This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv
- From: Florian Weimer <fweimer at redhat dot com>
- To: Caroline Tice <cmtice at google dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 14 Aug 2013 17:33:18 +0200
- Subject: Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv
- References: <CABtf2+SE75qwSodDpFjCEQ-DVFtY4B4dhVgMopNUA9z3FaCXRQ at mail dot gmail dot com> <520494FD dot 5030207 at redhat dot com> <CABtf2+SzFffNo78Ey9sr=wsrm8-5_3DzYAE6LALkYu06fHeHfQ at mail dot gmail dot com> <5207EE34 dot 6000409 at redhat dot com> <CABtf2+Sqm2PrKoGmug-FGveWze447uoTgzmmtJkWWgOQNHgBWA at mail dot gmail dot com> <5208C3BD dot 3090605 at redhat dot com> <CABtf2+QuhyWcmbQ_U+arO3k+B1EEaR31Xxf7n-jjiQHt6UjUeA at mail dot gmail dot com>
On 08/12/2013 07:07 PM, Caroline Tice wrote:
The feature is supposed to be active in production code (like the
Okay, and it makes sense to enable this in programs that run with
different privileges than the invoking user.
If a trust transition occurred during the past execve, libvtv must not
use the current directory to store files, or derive file paths from
environment variables. Using shared directories such as /tmp is also
tricky. (The current libvtv version in trunk has an arbitrary file
creation vulnerability because of the hardcoded path in /tmp.)
Realistically, I think libvtv can only log to standard error (or perhaps
syslog/the journal) if it detects it runs with elevated privileges.
One way to achieve that is to return dup(2) as the file descriptor if
logs_dir is NULL (after changing getenv to secure_getenv), instead of
setting logs_dir to ".". This means that unless the environment
variable is set, nothing would be logged to disk. I'm not sure if this
what you want. But it follows the principle of least surprise, though.
Creating log files in strange places because of a crash is unusual.
If you insist on dumping stuff into the current directory by default,
you'll have to use getauxval(AT_SECURE) (glibc 2.17 and later),
__libc_enable_secure (some glibc systems, but not Fedora and the ELs),
issetugid (Solaris and the BSDs) or an explicit comparison between
getuid()/geteuid() and getgid()/getegid() (all the rest, slightly unsafe
on Linux). I can write down this approach in more detail, it should
probably go into the Fedora security guide anyway.
I also noticed this in log_memory_protection_data:
log_fd = __vtv_open_log ("vtv_memory_protection_data_%d.log");
The "_%d" should probably be dropped because the argument is not a
Florian Weimer / Red Hat Product Security Team