[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Jul 2014 18:29:44 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: Status towards next release (1.1.4)
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
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.
