Summary: | [portage/sandbox-1.1] - security issues with file creation in /tmp | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | bartron <bartron> |
Component: | GLSA Errors | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | avenj, azarah, boulder_flight_technician, jrray |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | Flags: | plasmaroo:
Pending-
plasmaroo: Assigned_To? (plasmaroo) |
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
bartron
2003-05-29 18:39:49 UTC
For the first issue ... it removes the sandboxpids.tmp if its the only running instance, so that solves the issue. Same for the log files (excepts it always remove them at instance start - might just want to verify that). It is however an issue (with sandboxpids.tmp) if it is not the first (only) instance of sandbox running. I will have a look and try to get a more secure fix going. I can confirm this bug. Tried it this morning on a box without a separate /tmp partition and I could empty out any file on the same partition (except those belonging to running processes): --8<-- $ cd /tmp $ ln /sbin/ldconfig sandboxpids.tmp $ ls -l /sbin/ldconfig -rwxr-xr-x 2 root root 450340 Jul 20 03:21 /sbin/ldconfig $ ls -l /tmp/sandboxpids.tmp -rwxr-xr-x 2 root root 450340 Jul 20 03:21 /tmp/sandboxpids.tmp # emerge ufed <emerge output snipped> $ ls -l /sbin/ldconfig -rwxr-xr-x 1 root root 0 Aug 1 15:05 /sbin/ldconfig $ ls -l /tmp/sandboxpids.tmp ls: /tmp/sandboxpids.tmp: No such file or directory --8<-- As there are no traces as to what might have happened, I think this is rather dangerous! Using portage-2.0.48-r5. any news on this ? *** Bug 41708 has been marked as a duplicate of this bug. *** http://gentoo.twobit.net/misc/sandbox-security-040404.diff Will be applied once it's known to be proper. Feel free to test it and report back. http://gentoo.twobit.net/misc/sandbox-security-040404-3.diff In the file_open() call it runs a security check beyond the quick regular check that exists in file_exists(): lstat the file, check that it actually exists or return. Check that the number of hardlinks is not greater than 1, else unlink. Check that the file is not a symlink, else exit with error. Check that the file is a regular file, else exit with error. Check that the file is not world-writable, else unlink. Check that the UID and GID are in [root, getuid(), portage], else unlink. If it can't unlink... It bails with an error. That should cover everything, no? http://gentoo.twobit.net/misc/sandbox-security-040404-4.diff SpanKY pointed out a potential for a race condition between the unlink() and the fopen() calls. Added a second pass that ensures no foul play has occured. It bails on failure. This is available as portage-2.0.50-r3 which is the current stable portage. Okay -- is it safe to reassign this to security@ for a GLSA? Reassigning... GLSA sent out; http://article.gmane.org/gmane.linux.gentoo.announce/306. Closing bug as FIXED. |