[Linux-ia64] Location of hard coded IA32 libraries

[Linux-ia64] Location of hard coded IA32 libraries

[Don Dugger]

That's a pretty stong argument for not using the environment variable
approach.  If we go with using a hard coded path, like `/usr/ia32',
then there is no security hole.  This just becomes another tree that
has to have protected files the same way `/' needs protected files.

On Wed, Sep 05, 2001 at 09:45:11AM -0700, Rich Altmaier wrote:
> Don, I'm not expert, but will this open any security holes?
> That is, a non-root user must not be able to cause a fake library
> to be used.    Actually I suppose this area is well understodd
> already?
> Thanks, Rich
> 
> 
> Don Dugger wrote:
> 
> > Bill raises an interesting problem.  I'd like to suggest a solution and see
> > what everyone thinks.  Since all of the shared objects are loaded by code
> > in `ld-linux.so' I can modify the IA32 version of that library to first try
> > an absolute path and, if that fails, because it's missing or has the wrong
> > architecture, to then tack on a unique prefix, either something like
> > `/usr/ia32' or the contents of an environment variable like `LD_IA32_PATH'.
> >
> > This is a little ugly since all of the distro's would have to install s
> > special version of `ld-linux.so' but at least this is just one library
> > so that cuts the pain down a little bit.
> >
> > Does anyone have a better idea?
> >
> > On Wed, Sep 05, 2001 at 11:59:31AM -0400, Bill Nottingham wrote:
> > >
> > > The biggest problem I've seen is with programs that have hardcoded paths
> > > for shared objects they dlopen(). Obviously this fails pretty badly when
> > > the ia32 binary trys to dlopen() an ia64 library.
> > >
> > > Notably, this affects GTK+ when trying to use themes, and anything that
> > > uses PAM.
> > >
> > > Bill

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: [Linux-ia64] Location of hard coded IA32 libraries

[Jes Sorensen]

>>>>> "Don" = Don Dugger <n0ano@valinux.com> writes:

Don> That's a pretty stong argument for not using the environment
Don> variable approach.  If we go with using a hard coded path, like
Don> `/usr/ia32', then there is no security hole.  This just becomes
Don> another tree that has to have protected files the same way `/'
Don> needs protected files.

I don't see the problem for environment variables either, LD_IA32_PATH
should just be treated like LD_LIBRARY_PATH and do magic for suid
binaries. On the other hand if the sysadmin allows you to overwrite
/usr/ia32/lib then you are in the same situation as if the user can
overwrite /usr/lib ;-)

Cheers
Jes