>What this means is that if you use sudo to give yourself root privileges, your sudo authentication is not bound to the TTY in which you ran sudo. It applies to any process you (or malware running as you) start after authentication. The way Apple ships sudo it is, essentially, a giant privilege escalation vulnerability.
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:
> a malicious process on your system can still elevate itself by patching the shell (in memory, using /proc/id/mem)
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.
Or simply append `alias sudo="sudo evil.sh; sudo"` to .bash_profile.
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.
I think he only sandboxed apps are the ones from the App Store—Signing is orthogonal to sandboxing. Even signed apps that you get from anywhere other than then App Store aren't sandboxed.
In which case it's no different to Linux, OpenBSD or whatever.
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.
How so?
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...
I mean that most of the "important stuff" is running in user space. You can shut down the computer, spread viruses, and delete the user's most important files. The only administrator-owned files on a typical Windows installation happen to be the replaceable ones. The ones modifiable by a user are the custom, personal, and sometimes irreplaceable files.
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.
It's not (see my other reply), but for why it used to be allowed, it's because the traditional UNIX security boundary has been user accounts. Any process running as user id 1000 has the same permissions as any other process running as user id 1000, and so it's permitted to mess with those processes. It can't mess with user id 1001 or (of course) 0. But Minecraft running as uid 1000, Safari running as uid 1000, and bash running as uid 1000 are all considered as the same entity.
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:
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: