From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5455 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Status towards next release (1.1.4) Date: Sat, 12 Jul 2014 18:29:44 +0200 Message-ID: <20140712162944.GU28626@example.net> References: <20140712051035.GA15099@brightrain.aerifal.cx> <20140712072409.GT28626@example.net> <20140712145525.GH179@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1405182642 2631 80.91.229.3 (12 Jul 2014 16:30:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 16:30:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5460-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 12 18:30:35 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X60C3-0003vs-31 for gllmg-musl@plane.gmane.org; Sat, 12 Jul 2014 18:30:35 +0200 Original-Received: (qmail 24461 invoked by uid 550); 12 Jul 2014 16:30:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24453 invoked from network); 12 Jul 2014 16:30:34 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe07.swip.net; client-ip=5.175.194.69; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140712145525.GH179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5455 Archived-At: On Sat, Jul 12, 2014 at 10:55:25AM -0400, Rich Felker wrote: > > You can not know (and imho do _not_ have to pretend to) what is best or > > sensible for the actual deployment. > > I understand that configuring this matters for your usage case where > you're configuring ALL of the paths where configuration/data/etc. is > read from to isolate each program in its own bubble. However I don't > see any value in configuring this one location when other things (like > the place timezones are searched for) is fixed. Exactly! :) It is hardly tenable to hardcode the path to any database, including the timezone one. Fortunately TZ syntax allows escaping the trap (so actually per design it is not strictly enforced how the user may supply the timezone information, at least according to the gnu description). > > - If locale is mostly static (additions or changes to locale > > can be done at the same time as library recompilations/upgrades) > > then a "default" placement is totally irrelevant, but I must be > > able to choose the actual one at compilation time - I guess this is > > expected and hence a non-issue > > No, the intent is that they're produced independently of musl, or at > least independently of my part of the development/maintenance process. > I don't want to be a locale maintainer. BTW, locale definitions are a > much bigger "imposing policy" issue than a standard pathname. Then the library should not postulate nor hardcode the location, given that the expected maintenance routines for the data are unclear. > Runtime configuration of the path is a big problem for many usage > cases, possibly even if it's blocked for suid. The recent glibc > CVE-2014-0475 has me concerned and wanting to avoid any dubious > practices with how locales are searched out. This is potentially a I understand your concern about security but disallowing something at the library level just to prevent a certain possible mode of failure of a third party's flawed security model? This feels almost like designing flats without windows [no pun] to prevent children from falling out. > much bigger issue than timezones, because for timezones, invalid data > probably results in compromises no worse than a crash or information > leak. With locales, invalid data can result in full code execution > (via injection of %n into format strings, and possibly other ways). 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. The policy enforcer (ssh) would fare perfectly fine - just don't list the hypothetical MUSL_LOCALE_DIR in the variables allowed to be set, this will end the issue. Of course the Big Brother has to properly set the variable if locales are supposed to be available - or compile in the path to where he stores the "approved" locale defintions. Not worse than this and safe - unless the policy maker wants "allow all variables except a list", which is inherently unsafe. So this doesn't look like a security concern for musl. > On the other hand, runtime configuration is something I'd really like > to have, so that users can use locales that are not installed by the > system administrator and develop/test/debug locales without > installing. But this is a sufficiently big opening for environmental > state to alter the behavior of the program that I'm very concerned > about the safety of it and frustrated by the whole process... :( If you strongly feel for providing hardwired and unmutable behaviour then let the run-time envvar-driven choices be compile-time conditionals. This also will save several bytes for the control freaks :) while still allowing flexible deployment. Most of the traditional paranoia about the code being mislead by the user comes from the role of setuid in *nix which implies hardcoded references "as much as possible". In a setuid-free milieux (which we always have in a distributed/global context) this is a pure nuisance. By the way, it is easy to wrap binaries, resetting/protecting/checking variables accordingly to the actual purpose. This means the extra protection in a more complete form is available when needed, without putting it into the library and sacrificing functionality. Thanks for listening Rich, the decisions are yours anyway. Regards, Rune