> I don't see what the difference is in security architecture between a desktop app and a web app implementing the same scheme?
I just gave an example - execution environment is accessible by browser extensions. All the code and runtime data is visible for them with certain permissions.
Reading /proc/<PID>/mem requires access mode PTRACE_MODE_ATTACH_FSCREDS which is fundamentally same as access by using ptrace. Thus, kernel is indeed isolating process memory by default.
It is true, that often you get
PTRACE_MODE_ATTACH_FSCREDS with same UID/GId, but the most production systems have disabled ptrace or there are extra AppArmor rules to prevent its use. In most of the cases it is recommended to be disabled.
Thanks for the details. I didn't know Ubuntu was restricting ptrace by default now. Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently.
Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file.
> Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently.
You could try to set it similarly than Ubuntu is doing. See Yama kernel module [1], and set mode 1 (restricted).
> Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file.
AppArmor[2] is useful for this, you could define profile for the untrusted app, and it cannot access any other file than you allow.
I just gave an example - execution environment is accessible by browser extensions. All the code and runtime data is visible for them with certain permissions.