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).
Dan, cc'ing you on this since it directly affects you confcache.
Created attachment 43214 [details, diff] libsandbox.c additions for checking log paths
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)
Reassingning to security. Handling stable marking in bug #69147
Silently fixed with GLSA 200411-13
