loading of shared objects and executables

[Ángel González]

On 27/10/12 16:02, Michael Zintakis wrote:
>> A verified binary could bypass it by loading another program in a
>> different way, but as I guess you wouldn't "verify" such binary, that's
>> probably ok, since normal users will use mmap().
> I would aim to prevent such a case - I'll seek to modify the
> appropriate kernel functions responsible for loading/execution
> (process.c, exec.c etc) and will only allow the binary formats which
> can be verified to be loaded/executed. This should be OK, at least in
> my case, because I plan to use this on a hardened system, so the case
> of loading anything else, apart from elf-type binaries is not likely.
> Another possible way of "preventing" verification would be to replace
> ld.so with a rogue one, but I'll make the kernel check that as well.

No, I was refering to a "userland loader". Such as instead of using
mmap() with executable protection, doing a malloc() and then mprotect()
[not actually supported by POSIX, but it works in Linux].
As you are making a hardened system, you probably also want to forbid
writable and executable memory (when possible), so it will remove many
holes of that kind.

Still, the "rogue loader" cannot be completely detected just by kernel.
The extreme example would be a program that parsed each instruction and
executed it.
As I said, it is very unlikely that such program got verified :)