Bug 69137 – sys-apps/portage: SANDBOX_DEBUG(|_LOG) lacks sanity checks

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Brian Harring (RETIRED) 2004-10-27 07:13:56 UTC]

if this

declare -rx SANDBOX_DEBUG_LOG="/etc/this-is-not-a-good-thing"
declare -rx SANDBOX_DEBUG=1

was processed by bash/sandbox, the next sandbox interception of a func would result in the file being created, w/out the usual sandbox checks.

Usually, the attack has to disarm the sandbox- in this instance, the sandbox does the damage just via tweaking two vars.
Good reason to use userpriv me thinks.

In terms of fixing it, personally of the mind of just leaving an fd open-
if SANDBOX_DEBUG, then it writes to a high fd- granted, an attacker could just open a file, and dup it to that high fd, but the usual sandbox intercepts would check the first open, rather then current situation.

Either that, or when SANDBOX_DEBUG is on, write to a pipe in /tmp (and ensure the privs on the pipe are sane).

[Comment 1 Brian Harring (RETIRED) 2004-10-27 07:15:26 UTC]

Dan, cc'ing you on this since it directly affects you confcache.

[Comment 2 Brian Harring (RETIRED) 2004-11-03 05:17:15 UTC]

Created attachment 43214 [details, diff]
libsandbox.c additions for checking log paths

[Comment 3 Nicholas Jones (RETIRED) 2004-11-05 01:15:19 UTC]

portage-2.0.51-r3 (dispatch-conf, sandbox, and dohtml-for-python2.2)

Arches please report back bugs/problems/success rather than
directly bumping for your arch.

Reason, if you are inclined to ask why:
I prefer to have everyone working rather than a subset. Bugs are less
fun to manage across arches and for sanity, one set of bugs at a time
is better.

(I'm also possessive and anal about the order of the flags. :-p)

[Comment 4 Sune Kloppenborg Jeppesen (RETIRED) 2004-11-05 01:41:43 UTC]

Reassingning to security.

Handling stable marking in bug #69147

[Comment 5 Sune Kloppenborg Jeppesen (RETIRED) 2004-11-07 10:52:37 UTC]

Silently fixed with GLSA 200411-13