Vishwajeet wrote: > Q-2 If my executable has a dependency then it should load that dependency > only from /usr/lib/secure or /lib/secure. In my another program it is not > taking from /usr/lib/secure rather it is taking from /usr/lib/ or /lib as > default path for looking a shared object.
ld.so.1(1) and the Linker and Libraries Manual cover security, but we obviously haven't clarified everything, as questions of this type do resurface now and again. Try this: If I have an application which has dependencies on standard OS libraries, and it's own libraries in /usr/ISV/lib, then all I need is to encode a runpath (ld(1) -R) to this non-standard directory. If I make the application secure, then it can contain the same runpath, to find its /usr/ISV/lib dependencies, and will work fine. Both applications are exercising "basic" dynamic linking. But, you can affect dynamic linking by altering a runtime process beyond the basic linking. You can inject new objects with LD_PRELOAD, or point to different dependencies with LD_LIBRARY_PATH. It is these mechanisms, that can dynamically alter a process, that are dangerous when used with secure applications. And that's where the /lib/secure family of directories come in. If you wish to LD_PRELOAD against a secure application, then the object to be preloaded must be in a secure directory. If you wish to point at different dependencies with LD_LIBRARY_PATH, then you can only point at a secure directory. In a nutshell - a secure application can find dependencies anywhere that the applications runpath, or any dependencies runpaths, point to. But if you want to alter the process at runtime, LD_PRELOAD and LD_LIBRARY_PATH can only be used to point to secure directories. (there are other limitations on runpaths, they must start with "/", can't use $ORIGIN, etc.) NOTE. If your secure application has a dependency on /lib/ISV, then this library better have suitable permissions that don't allow someone to modify its contents. The dynamic dependency model we have is a compromise between the security folks, who want very restricted access to dependencies, and secure application developers who have asked for some flexibility with respect to finding "alternate" dependencies. There's still rope out there, so you shouldn't blindly make an application secure. Personally, I wish there was a security cheat-sheet, with a column "I need to make my app secure to do this", and a column "you can use this alternative, non-secure mechanism to do that". Perhaps this already exists. -- Rod.
