Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

[Florian Weimer <fweimer at redhat dot com>]

On 08/12/2013 07:07 PM, Caroline Tice wrote:

> The feature is supposed to be active in production code (like the
> stack protector).

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 
format string.


--
Florian Weimer / Red Hat Product Security Team