I understand your reasoning, but I still disagree. I'll add a bit more information as to why:

> " It is not, it is implicit just as you described because for both cases their permission is implied because of who owns the process and fs acls. On my Mac for example, I couldn't troubleshoot something in my browser process both as user and root with gdb because the browser's publisher didn't give gdb an explicit permission to debug it but it turns out the "builtin" lldb had permission so I was able to attach and debug."

You're just describing extra permissions in osx - I believe related to code signing. Any system can introduce additional privilege checks (linux has yama/ptrace_scope), but this doesn't change the underlying permissions model.

Furthermore, the permission is absolutely implied and this can be directly demonstrated on linux: You can simply open up /proc/$pid/mem and read/write values into the process's memory. This is sufficient to do anything. All memory can be read from and written to (provided the pages are writeable).

> "preloading a shared library or using ptrace to attach to a process is not explicitly defined in the acl"

It is. Specifically: The executable handler for /bin/ls will be (on my system) /lib64/ld-linux-x86-64.so.2. The explicit ACL is the execute bit on /lib64/ld-linux-x86-64.so.2 (to run that linker with all its options) and the executable /bin/ls (the invoking file). There are also permission checks on all the libraries which will be linked.

You can test this by copying the linker:

cp /lib64/ld-linux-x86-64.so.2 /tmp/mylinker

and then if you like, modifying it and running it explicitly:

/tmp/linker /bin/ls

There are explicit permission checks on all of these things -- they're just generally set to be accessible by everyone.

Users can also compile their own linkers and execute system binaries however they wish -- it does not matter. The permission is to run code -- any code.

> "read and write apply to the file, not the process"

As I mentioned above, this is explicitly not true. Memory pages on linux are represented as a flat file and they have standard unix permissions allowing the user to read their own memory in their own processes.

This is also true of a process's file descriptors, including ephemeral descriptors such as pipes, sockets, and what have you. It's all accessible using basic filesystem syscalls like open(), seek(), read(), write().

> "In an ideal world, in addition to PKI/signatures, ELF headers would contain explicit permissions like this."

There are indeed ways to do this but-

> "So, for example, htop/top would disallow LD_PRELOAD "

No! Why? There is no reason for this. It's not a security feature and it cannot serve a useful purpose. Anything you might do with LD_ vars and top you could do equally well by just copying and editing top.

> "and the kernel/LSM would police against permission header tampering without root or LSM-specific credentials even by the owner (ideally not root)"

These are features that you would use for a locked down device, but these types of features have no use on a development workstation where users are allowed to write code.

> "This would make a lot of usermode rootkits useless (forcing them to use other means of course). Execute acl only defines the permission to start the program not what others can do to the program during its runtime."

I think you're describing how to lock down an appliance. I'm talking about a development workstation.