Lazy loading can thunk through kernel so that ld.so service loads things into the process - and preferably strict loading should be used.

As far as I'm aware, it's quite common in microkernel-based OSes to implement even ELF loading, dynamic linking, etc. inside system libraries loaded inside the process creating the new process. So the parent process basically constructs the child process, which means you could easily design an OS such that the parent needs access to the library files, but the child doesn't.

It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly.

Restricting what programs can do is a great way to prevent experimentation and hinder progress.

>It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly.

It is not pointless, but it is also not perfect. That's why we have defense in depth. Where instead of having one perfect moat to protect the castle, you also have alligators and witches that turn people into frogs. :P

What do you mean by loading files "as code". Do you mean setting the execute bit on memory pages? You need to have the appropriate permissions to do that, and a locked down system wide policy can prevent programs from doing that as well.