Thread: Re: PG Patch (fwd) [openserver patch followup #2]
2nd followup from Kean. LER ------------ Forwarded Message ------------ Date: Friday, July 18, 2003 23:43:55 -0700 From: Kean Johnston <jkj@sco.com> To: Larry Rosenman <ler@lerctr.org> Cc: Subject: Re: PG Patch Larry Rosenman wrote: > I got a question from the PG Core Team (Bruce Momjian) about the > rpathdir portion of > your patch. > > Why can't it use libdir? Or can we wrap it in .if (port,=,sco) type > stuff? Sorry I forgot to anwer that portion of the question. The only place that used RPATHDIR *is* wrapped up in if port=sco. But why not use just libdir? Well the rule for making shared libraries is shared across multiple makefiles. Although I only set it for the main interface libraries, I had originally set it for all the dynamically loadable modules too, and for those, libdir isnt what you want, you want datadir or whatever its called (I'm too lazy to go look now). So I needed variable the lower level makefiles could specify that get used in the top level makefile. Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine <= 2.7, or any OSR5 system < 507 or any FreeBSD system <= 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. Suffice it to say that I believe that *EVERY* .so should have an absolute SONAME. There are still a few I need to clean up in 507 but most of them are correct. If you're not on the up-and-up with DT_RUNPATH, DT_RPATH and SONAME ELF headers I suggest for light reading that you peruse the gABI. Kean ---------- End Forwarded Message ---------- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman writes: > Why do this at all? Security. Having shared libraries without full SONAME's > is a big security risk. There have been any number of huge explots based > around this. Point me at any Solaris machine <= 2.7, or any OSR5 system < > 507 or any FreeBSD system <= 4.0 and I can get root with 1 tiny program > thats on all of them: xterm. It has long upset me, and I am done trying to > convince them, but libtool encourages the worst possible .so practices, and > may programs seem to have picked up those equally bad practices. There is > no need for futzing with ld.conf and the like if people take the time to > construct shared libraries propperly. Yes it can be a pain to bootstrap but > the reward is very well worth the effort it takes. These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. -- Peter Eisentraut peter_e@gmx.net
--On Wednesday, July 23, 2003 12:20:34 +0200 Peter Eisentraut
<peter_e@gmx.net> wrote:
> Larry Rosenman writes:
>
>> Why do this at all? Security. Having shared libraries without full
>> SONAME's is a big security risk. There have been any number of huge
>> explots based around this. Point me at any Solaris machine <= 2.7, or
>> any OSR5 system < 507 or any FreeBSD system <= 4.0 and I can get root
>> with 1 tiny program thats on all of them: xterm. It has long upset me,
>> and I am done trying to convince them, but libtool encourages the worst
>> possible .so practices, and may programs seem to have picked up those
>> equally bad practices. There is no need for futzing with ld.conf and the
>> like if people take the time to construct shared libraries propperly.
>> Yes it can be a pain to bootstrap but the reward is very well worth the
>> effort it takes.
>
> These concerns might have some merit, but the solution could not possibly
> be to only fix this on one platform, because the mechanisms are the same
> everywhere. That said, it seems the universal practice is not to put full
> sonames into shared libraries, so it seems better that our libraries
> follow that practice. Otherwise it will be only a matter of time before
> someone comes out of the wood and claims that libraries will full sonames
> are a big whatever-else problem.
Universal Practice does NOT equal Security and Usability.
Please consider what Kean is saying here.
Kean,
Please respond.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman writes: > Universal Practice does NOT equal Security and Usability. > > Please consider what Kean is saying here. What Kean is saying is that your system is insecure if you have a setuid executable that references shared libraries with nonabsolute sonames and you have a system (an "older system") that contains a particular bug in its run-time dynamic loader that it obeys LD_LIBRARY_PATH for setuid executables. That is fairly common knowledge, and that's why LD_LIBRARY_PATH is ignored for setuid executables on all properly functioning operating systems. If your system is broken in that particular way, upgrade your system or don't use setuid programs at all. Those are the only sane choices. It is not an acceptable choice to disable all valid uses of nonabsolute sonames for all users, just because some users are running on broken systems with obvious security flaws. -- Peter Eisentraut peter_e@gmx.net
--On Friday, July 25, 2003 09:37:04 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Larry Rosenman writes: > >> Universal Practice does NOT equal Security and Usability. >> >> Please consider what Kean is saying here. > > What Kean is saying is that your system is insecure if you have a setuid > executable that references shared libraries with nonabsolute sonames and > you have a system (an "older system") that contains a particular bug in > its run-time dynamic loader that it obeys LD_LIBRARY_PATH for setuid > executables. That is fairly common knowledge, and that's why > LD_LIBRARY_PATH is ignored for setuid executables on all properly > functioning operating systems. > > If your system is broken in that particular way, upgrade your system or > don't use setuid programs at all. Those are the only sane choices. It is > not an acceptable choice to disable all valid uses of nonabsolute sonames > for all users, just because some users are running on broken systems with > obvious security flaws. I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? All the SYSTEM SUPPLIED .so's on UnixWare use an absolute DT_SONAME, and I feel that we should build libpq to supply same on UnixWare, and Kean suggests that the prefered, SCO recommended way on OpenServer is to do the same. I belive that the issue is not broken systems, but broken practice. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman writes: > I disagree STRONGLY with what you are saying here. What harm does it do to > add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. > I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. -- Peter Eisentraut peter_e@gmx.net
--On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Larry Rosenman writes: > >> I disagree STRONGLY with what you are saying here. What harm does it do >> to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? > > We can discuss adding the ability, but I'm against enforcing it by > default. > >> I belive that the issue is not broken systems, but broken practice. > > No, the issue is precisely that someone is proposing to break reasonable, > useful practice to accomodate broken systems. No one is claiming that > absolute sonames make the system more featureful or useful. In fact, it > was admitted that it would have the reverse effect. The only argument for > absolute sonames that was brought forth was that some older systems have > security holes that can be worked around in this manner. For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to specify -R/usr/local/pgsql/lib on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH environment variable set. The absolute DT_SONAME will fix that issue on THIS platform, which is why the ABILITY of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Finally I understand the issue, I think. But wouldn't an ordinary user on SCO wanting to install a private copy of Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME? If so, that seems to me to mandate that this not be in the vanilla distribution. OS Vendors commonly make changes like this in software versions they distribute - that's a different thing from putting it in the standard distribution, ISTM. The benefit Larry cites seems to me to be small - presumably his Makefiles must include "-L /usr/local/pgsql/lib", so adding "-R /usr/local/pgsql/lib" doesn't look like a big thing. Adding an Rpath to executables to use libs in non-standard locations is very common, surely? Maybe this needs to be YACO (yet another configure option) cheers andrew Larry wrote > > > --On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut > <peter_e@gmx.net> wrote: > >> Larry Rosenman writes: >> >>> I disagree STRONGLY with what you are saying here. What harm does it >>> do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? >> >> We can discuss adding the ability, but I'm against enforcing it by >> default. >> >>> I belive that the issue is not broken systems, but broken practice. >> >> No, the issue is precisely that someone is proposing to break >> reasonable, useful practice to accomodate broken systems. No one is >> claiming that absolute sonames make the system more featureful or >> useful. In fact, it was admitted that it would have the reverse >> effect. The only argument for absolute sonames that was brought forth >> was that some older systems have security holes that can be worked >> around in this manner. > For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, > or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to > specify -R/usr/local/pgsql/lib > on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH > environment > variable set. > > The absolute DT_SONAME will fix that issue on THIS platform, which is > why the ABILITY > of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. > > LER > > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > > ---------------------------(end of > broadcast)--------------------------- TIP 7: don't forget to increase > your free space map settings
--On Friday, July 25, 2003 03:28:55 -0500 Andrew Dunstan <andrew@dunslane.net> wrote: > > Finally I understand the issue, I think. > > But wouldn't an ordinary user on SCO wanting to install a private copy of > Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME? > If so, that seems to me to mandate that this not be in the vanilla > distribution. OS Vendors commonly make changes like this in software > versions they distribute - that's a different thing from putting it in the > standard distribution, ISTM. > > The benefit Larry cites seems to me to be small - presumably his Makefiles > must include "-L /usr/local/pgsql/lib", so adding > "-R /usr/local/pgsql/lib" doesn't look like a big thing. Adding an Rpath > to executables to use libs in non-standard locations is very common, > surely? except for things like PHP that create YASO (Yet Another Shared Object), and do NOT require the base EXECUTABLE to be recompiled, and use broken tools (e.g. libtool) to build the .SO..... > Maybe this needs to be YACO (yet another configure option) the option proposed would Do the right thing with a private copy, as it would make the DT_SONAME for their private copy their path. LER ] > > cheers > > andrew > > Larry wrote >> >> >> --On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut >> <peter_e@gmx.net> wrote: >> >>> Larry Rosenman writes: >>> >>>> I disagree STRONGLY with what you are saying here. What harm does it >>>> do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? >>> >>> We can discuss adding the ability, but I'm against enforcing it by >>> default. >>> >>>> I belive that the issue is not broken systems, but broken practice. >>> >>> No, the issue is precisely that someone is proposing to break >>> reasonable, useful practice to accomodate broken systems. No one is >>> claiming that absolute sonames make the system more featureful or >>> useful. In fact, it was admitted that it would have the reverse >>> effect. The only argument for absolute sonames that was brought forth >>> was that some older systems have security holes that can be worked >>> around in this manner. >> For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, >> or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to >> specify -R/usr/local/pgsql/lib >> on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH >> environment >> variable set. >> >> The absolute DT_SONAME will fix that issue on THIS platform, which is >> why the ABILITY >> of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. >> >> LER >> >> >> >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 972-414-9812 E-Mail: ler@lerctr.org >> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 >> >> >> ---------------------------(end of >> broadcast)--------------------------- TIP 7: don't forget to increase >> your free space map settings > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > > If your system is broken in that particular way, upgrade your system or > > don't use setuid programs at all. Those are the only sane choices. It is > > not an acceptable choice to disable all valid uses of nonabsolute sonames > > for all users, just because some users are running on broken systems with > > obvious security flaws. > > I disagree STRONGLY with what you are saying here. What harm does it do to > add the ABILITY for a port to use a ABSOLUTE DT_SONAME? > > All the SYSTEM SUPPLIED .so's on UnixWare use an absolute DT_SONAME, and I > feel > that we should build libpq to supply same on UnixWare, and Kean suggests > that > the prefered, SCO recommended way on OpenServer is to do the same. > > I belive that the issue is not broken systems, but broken practice. It is a broken system. Setuid shouldn't honor that environment variable, because you are never going to be sure you catch all the shared library file creations. Also, once we hard code it, you can't move the library around later if you wish. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073