On Thu, Apr 19, 2012 at 11:52, Manfred Schwarb <manfre...@gmx.ch> wrote:
> Am 19.04.2012 09:25, schrieb Janne Blomqvist:
>
>> On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb<manfre...@gmx.ch> wrote:
>>>
>>> Hi Janne,
>>>
>>>
>>>>
>>>> - If the program is privileged, we shouldn't trust path style
>>>> environment variables. The patch fixes this for TMPDIR and also for
>>>> the logic figuring out where addr2line is.
>>>
>>>
>>>
>>>
>>> I did not test it, but if I remember right, the use of geteuid() and
>>> friends
>>> does prevent static compilation, resp. static compilation does seem
>>> to work, but it needs a matched dynamic library nonetheless,
>>> which means if you relocate your statically linked program to another
>>> box with differing glibc, you get runtime errors?
>>>
>>> Or is the use of static programs already broken so it does not matter?
>>> If this security feature would prevent use of static programs, it would
>>> not be worth it, I think.
>>
>>
>> getuid and friends are already used in other parts of the runtime
>> library, so if static linking to glibc is broken it was broken before
>> as well.
>>
>> The Glibc FAQ says:
>>
>> 2.22. Even statically linked programs need some shared libraries
>> which is not acceptable for me. What can I do?
>>
>> {AJ} NSS (for details just type `info libc "Name Service Switch"') won't
>> work properly without shared libraries. NSS allows using different
>> services
>> (e.g. NIS, files, db, hesiod) by just changing one configuration file
>> (/etc/nsswitch.conf) without relinking any programs. The only
>> disadvantage
>> is that now static libraries need to access shared libraries. This is
>> handled transparently by the GNU C library.
>>
>>
>> I'm not sure of the details of what happens, or under which exact
>> circumstances it works or not, when one runs a statically linked
>> program on another machine with a different glibc version.
>>
>
> The nasty thing is, the runtime error does not happen at program start, but
> at the point of actual invocation of the *uid call. So this may come as
> a real surprise for the user if such functions are seldom called in the
> binary, e.g. in some error path.
>
> And the really ugly thing is, there seems to be an incompatible break
> between
> glibc 2.11 and 2.12 in this very NSS stuff.
> I recently stumbled over https://bugs.gentoo.org/show_bug.cgi?id=332927,
> when
> the provider decided to upgrade glibc on the server (sic!).
> [ And, it was a c-program that was crashing, my static fortran programs were
> still running fine ]
>
> As traditionally a lot of fortran code is statically compiled, I just wanted
> to make aware that the more of such calls are added, the more likely users
> will
> get surprises.
> I guess relocation of binaries to other boxes is not uncommon in the HPC
> sector,
> and having a crash after some weeks of runtime due to this is not really
> funny...
That shouldn't be an issue then as with the patch __secure_getenv is
called during library initialization, so if it's going to crash it
will crash immediately.
Also, I suspect getuid and friends are not actually part of the NSS
stuff. The uid/gid/euid/egid are maintained for each process by the
kernel, and NSS only handles translation to/from the numeric id's to
string values, IP address lookup and so forth.
--
Janne Blomqvist
