On most desktop operating systems, that functionality has been disabled. Ubuntu, Fedora, etc. all have Yama, which disables the ability for one process to access another's process via ptrace or ptrace-equivalent mechanisms (like /proc/*/mem) without special permissions. OS X has no procfs, but the equivalent functionality, using task ports, has had similar restrictions since the 10.5 days -- see `man taskgated`. You can't call task_for_pid() without having a particular code-signing entitlement or having administrator privileges.
This is why Xcode prompts you for administrator privileges when you first run it; gdb / lldb needs to be able to trace other processes and access their memory, and a normal process can't do that.
Although, OS X is a bit like Windows. A bad program running in userspace can essentially ruin your system as much as a program running as root. Privilege escalation is not a relatively big deal when you can `shred -u ~/` without root.
Erm, OS X has sandboxing. So, no. Except if you use unsigned third party stuff.
As long as its your account files that matter, and you're running an app un-sandboxed, then it has access to them.
Nothing Windows or OS X particular about it.
As about "ruining your system", no, without root privileges it cannot, in either OS X or Windows. Of course it can if there's a privilege escalation bug, but there are tons of those for GNU/Gnome/KDE packages too.
...like Windows. A bad program running in userspace can essentially
ruin your system as much as a program running as root.
Are you talking about pre-Vista - i.e. versions of Windows in which the user created during first run was an Administrator, and UAC didn't exist - though you could certainly create non-administrator accounts? Vista came out eight years ago...
Or do you mean pre-NT, when there was no separation of any kind? NT came out 22 years ago...
This is mostly true on personal Linux machines as well. I'm just expressing my opinion that you don't need root access to pwn someone's machine.
In this model, the real problem here is sudo, which bridges a uid-1000 session to a uid-0 one. If you're administering a security-conscious, multi-user UNIX system, you should not be using sudo from your regular account. Either make a separate account and log in as that, or log in as root directly. (But if you want your Minecraft and your bash to not be able to interact with each other, the traditional approach doesn't have an answer for you.)
Of course, most UNIX deployments today are not multi-user remote-access systems, the way they were 30+ years ago when this policy was set. Most desktop UNIX deployments are effectively single-user systems, and the UNIX isolation model doesn't make much sense there. As a stopgap measure, direct access to another process's memory has been disallowed, but there are other ways for processes that share UID to mess with each other.
However, the most common single-user UNIX systems today are smartphones, either Android (Linux) or iOS (BSD + stuff). Android takes advantage of the UNIX model by assigning each app its own user ID. Angry Birds running as uid 1000 cannot mess with the Chase mobile app running as uid 1001. iOS technically runs all apps with the same uid, but applies extensive kernel-level sandboxing to limit the ways that apps can interact with the rest of the system, which essentially eliminates the rest of the leakiness.
There's a Chromium security document that expands on the traditional "1-part principal" model (identity of the human) and how we need to get to "2-part principals" (identity of the human + identity of the app), which I hope that someone will figure out how to extend to desktop UNIX someday:
https://www.chromium.org/Home/chromium-security/prefer-secur...
But even if you enable TTY tickets, a malicious process on your system can still elevate itself by patching the shell (in memory, using /proc/id/mem) to inject commands alongside the original sudo command. For example:
User types:
shell executes: