[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140714175525.GA9884@brightrain.aerifal.cx>
Date: Mon, 14 Jul 2014 13:55:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Status towards next release (1.1.4)
On Sat, Jul 12, 2014 at 01:00:08PM -0400, Rich Felker wrote:
> > Allowing a user to set environment variables is giving her freedom to
> > control her applications iow a policy question. The low level library has
> > no proper knowledge to make policy decisions.
> >
> > Again, I feel you assume more responsibility for musl than is due.
>
> I partly agree with you here, and that's why I've raised a question on
> oss-security as to whether CVE-2014-0475 was even a valid
> vulnerability rather than just an ordinary non-security bug.
See the answer from glibc's side here:
http://www.openwall.com/lists/oss-security/2014/07/14/3
They consider absolute pathnames or directory traversal outside of the
locale base to be a vulnerability, but allow the base to be overridden
via LOCPATH which also comes from the environment. To me this seems a
bit contradictory, but I _think_ the idea is that they see it as
important to accept and trust LC_* from the user even when the source
of these vars is a different privilege domain, so that a properly
localized environment can be provided to the user. (Presumably,
LOCPATH and other arbitrary non-whitelisted env vars would not be
accepted in such situations, and suid programs would not honor
LOCPATH.)
If we want to follow a similar approach, I think we should at least
consider using the same var (LOCPATH) and having the musl locale data
reside in a directory under that base, since this would avoid adding
new vars that users need to be aware of that could affect the behavior
and safety (but hopefully, we've covered all the safety issues) of
programs.
By the way, as far as absolute pathnames go, we're under no obligation
from POSIX to support them, since we do not support the POSIX
localedef system (leading / means the LC_* refers to a locale
definition built by the localedef utility). If we do decide we want to
support them, on the other hand, we should use a different syntax
so as not to overlap with the form for POSIX localedef (which we don't
support).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
