loading of shared objects and executables

[Michael Zintakis]

Hi Roman,


Bolshakov, Roman wrote:
> I also studied that in the spring. You can find a lot of details on the page: http://www.acsu.buffalo.edu/~charngda/elf.html
>   
Very good reference this, thank you - I'll look into it in more detail 
over the weekend! OK, in a nutshell, what I am after is, basically, two 
things:

1. Find the portion of the kernel code, which is responsible for the 
initial loading the file for execution (i.e. when I type "iptables" from 
the command line for example). This will help me to modify that code so 
that the file which is about to be loaded is "verified" first and raise 
a security exception if something is wrong with it.
2. Once I've done that, if there is a possibility to identify all .so 
(shared objects) on which this executable depends (by looking at its 
headers for example), I could do the same as step 1 above for all 
dependent .so files. If not, then I'll have to pass control to ld.so and 
intercept the point prior to where these .so are about to be loaded, so 
that I could do the verification - as in step one above, but for the 
shared objects. If everything checks out, then I'll pass control over to 
ld.so.

I am guessing the picture when statically compiled executables are run 
is more or less the same with the exception of loading Ñ‚Ñ
е shared 
libraries, as they are included as part of the file which needs to be 
executed - am I correct in thinking that?

> Dynamic linker is loaded by kernel after the kernel reads ELF headers.
And it is precisely at that point I need to take control to "verify" the 
executable and, if possible, all .so files on which this file depends.

>  Then it passes control to the entry point of the linker. If you use glibc the entry point is named _dl_start. So, in general, you need to make breakpoint on _dl_start.
>   
I guess I would need to do that only if I could not find the .so files 
on which this executable depends, otherwise the verification could be 
done much earlier and I could then let ld.so do its job, right?